Commit 02abc23e authored by Walter Heck's avatar Walter Heck

Rename 1.7 release into 2.0

parent d419786e
## OpsTheater Release Checklist for Release 1.7.0
**Following checks need to be performed after every release :**
- Check if you can login into following using your web browser :
- [ ] Foreman
- [ ] Gitlab
- [ ] Mattermost
- [ ] Icinga
- [ ] Grafana
- [ ] Kibana
- [ ] Check if you are able to send message using Mattermost.
- [ ] Check if you are able to create a user in Foreman and can login with that user.
- [ ] Check if you can see the logs coming up for OpsTheater components in Icinga Web UI.
- [ ] Try to search for a host in Kibana and check if you are getting logs of that host.
[ ] Check if you can create users and usergroups in Icinga
**Release specific Checks :**
*These checks will change on every release and will be more specific for the new changes that we are introducing in this release.*
- [ ] Login to Grafana web UI and check if you can see different metrics in Grafana
[ ] Login to grafana and check that you can see two datasources. Edit each one of them and press "Test Connection" to make sure they work.
- [ ] Login to Kibana web UI and try to search for logs having source as "/var/log/puppetlabs/puppetserver/puppetserver-access.log". Check if the value of field timestamp is same as the time given in message field
# Prerequisites
* Make sure you have read https://gitlab.olindata.com/opstheater/opstheater-docs/blob/master/1.7/deployment/scenario.md
* Make sure you have read <https://gitlab.olindata.com/opstheater/opstheater-docs/blob/master/1.7/deployment/scenario.md>
* Make sure you have installed the following on your host machine:
* virtualbox (http://virtualbox.org)
* vagrant (https://www.vagrantup.com/)
* vagrant plugin oscar (https://github.com/oscar-stack/oscar)
* make sure you have min. 6G RAM available to run the machine
* Make sure you have installed the following on your host machine:
* virtualbox (<http://virtualbox.org>)
* vagrant (<https://www.vagrantup.com/>)
* vagrant plugin oscar (<https://github.com/oscar-stack/oscar>)
* make sure you have min. 6G RAM available to run the machine
You can install oscar plugin for vagrant with the following command:
......@@ -24,22 +24,22 @@
# Setting up opstheater in an oscar environment
* Clone the opstheater repository on your host machine:
* Clone the opstheater repository on your host machine:
```
git clone git@gitlab.olindata.com:opstheater/opstheater.git
```
* Change to ‘develop’ branch to get the latest code:
* Change to ‘develop’ branch to get the latest code:
```
git checkout -b develop origin/develop
cd opstheater/deploy/vagrant-oscar
```
* All the deployment files and configurations are in the `opstheater/deploy/vagrant-oscar` directory.
* All the deployment files and configurations are in the `opstheater/deploy/vagrant-oscar` directory.
* Bring up the puppet master (This will take a looong time!) vm and log into it:
* Bring up the puppet master (This will take a looong time!) vm and log into it:
For Puppet Enterprise:
```
......@@ -63,7 +63,7 @@
```
Don’t forget to add master.opstheater.vm to your hosts file.
* Now bring up one or more machines with oscar on your host machine:
* Now bring up one or more machines with oscar on your host machine:
```
vagrant up mysql
vagrant up icinga2
......@@ -75,6 +75,6 @@
NOTE: you might have to run puppet a number of times on each node to make sure it fully puppetises itself. Some of the initial runs might have errors but they will go away as the puppet runs on all servers start happening.
* You might also want to install r10k or puppet-librarian on your host machine and install the modules the opstheater repo uses on your host so you can browse through them.
* You might also want to install r10k or puppet-librarian on your host machine and install the modules the opstheater repo uses on your host so you can browse through them.
TODO: Add instructions for r10k setup
## OpsTheater Release Checklist for Release 1.7.0
**Following checks need to be performed after every release :**
- Check if you can login into following using your web browser :
- [ ] Foreman
- [ ] Gitlab
- [ ] Mattermost
- [ ] Icinga
- [ ] Grafana
- [ ] Kibana
- [ ] Check if you are able to send message using Mattermost.
- [ ] Check if you are able to create a user in Foreman and can login with that user.
- [ ] Check if you can see the logs coming up for OpsTheater components in Icinga Web UI.
- [ ] Try to search for a host in Kibana and check if you are getting logs of that host.
- [ ] Check if you can create users and usergroups in Icinga
**Release specific Checks :**
*These checks will change on every release and will be more specific for the new changes that we are introducing in this release.*
- [ ] Login to Grafana web UI and check if you can see different metrics in Grafana
- [ ] Login to grafana and check that you can see two datasources. Edit each one of them and press "Test Connection" to make sure they work.
- [ ] Login to Kibana web UI and try to search for logs having source as "/var/log/puppetlabs/puppetserver/puppetserver-access.log". Check if the value of field timestamp is same as the time given in message field
# Release process
This borrows heavily and is modeled after: http://doc.gitlab.com/ce/release/monthly.html
This borrows heavily and is modeled after: <http://doc.gitlab.com/ce/release/monthly.html>
**NOTE: This is a guide used by OlinData BV for handling releases of OpsTheater. As an end user you do not need to use this guide.**
......@@ -15,23 +15,23 @@ Patch release, for serious bugs or security problems.
# Monthly Release Internal Process
1. The process starts the 23rd of every month, in which we evaluate the stability and inclusion of newer versions of our included packages. The release manager decides on a version of all supporting packages and creates a ChangeLog to be included with the release and documented in this repository under releases/x.x.x_changelog.md
1. The process starts the 23rd of every month, in which we evaluate the stability and inclusion of newer versions of our included packages. The release manager decides on a version of all supporting packages and creates a ChangeLog to be included with the release and documented in this repository under releases/x.x.x_changelog.md
2. First thing that occurs the release manager opens a issue for the new release and to keep track of the release. You can refer this one for example : https://gitlab.olindata.com/opstheater/opstheater/issues/10
2. First thing that occurs the release manager opens a issue for the new release and to keep track of the release. You can refer this one for example : <https://gitlab.olindata.com/opstheater/opstheater/issues/10>
3. After this the release manager creates a release-x.x.x tag from the master branch. Typically monthly releases are sub-releases, so it should increment the Y in x.y.z, making 1.2.3 into 1.3.0. The final version octet is reserved for emergency bug/security patches, and the first octet is reserved for us to designate major evolutions in the software at our own discretion.
3. After this the release manager creates a release-x.x.x tag from the master branch. Typically monthly releases are sub-releases, so it should increment the Y in x.y.z, making 1.2.3 into 1.3.0. The final version octet is reserved for emergency bug/security patches, and the first octet is reserved for us to designate major evolutions in the software at our own discretion.
4. From this release branch, the release manager attempts a fresh installation of all of the currently supported services on a staging-ish environment, typically using our primary provider DigitalOcean or a local vagrant setup.
4. From this release branch, the release manager attempts a fresh installation of all of the currently supported services on a staging-ish environment, typically using our primary provider DigitalOcean or a local vagrant setup.
5. Form this local installation release manager will make a list out current stable versions of the tools included in OpsTheater.
5. Form this local installation release manager will make a list out current stable versions of the tools included in OpsTheater.
6. If this installation happened without problem, then (ideally) a fresh installation is setup from the previous release, and an upgrade installation is performed and tested. This above process is expected to take 1-3 days depending on our level of automation and problems occurred during installation/upgrading/testing. Patches can be made to fix any release problems and committed directly to the release branch to be merged back into the master with a PR after released.
6. If this installation happened without problem, then (ideally) a fresh installation is setup from the previous release, and an upgrade installation is performed and tested. This above process is expected to take 1-3 days depending on our level of automation and problems occurred during installation/upgrading/testing. Patches can be made to fix any release problems and committed directly to the release branch to be merged back into the master with a PR after released.
7. If the release testing will take more than 3 days, we evaluate the progress, changes, and situation and consider postponing deploy or proceeding with it.
7. If the release testing will take more than 3 days, we evaluate the progress, changes, and situation and consider postponing deploy or proceeding with it.
8. Create release notes and a blog post for the olindata.com blog.
8. Create release notes and a blog post for the olindata.com blog.
9. Once the upgrade installation is succeeded then release manager need to create a new directory in opstheater-docs reposiroty cloning previous release directory and need to update the documents in the new directory according to the new release for example release manager need to update upgrade.md with the steps that need to be performed for upgrade installation.
9. Once the upgrade installation is succeeded then release manager need to create a new directory in opstheater-docs reposiroty cloning previous release directory and need to update the documents in the new directory according to the new release for example release manager need to update upgrade.md with the steps that need to be performed for upgrade installation.
10. After this release manager need to update releasechecklist.md in current release branch of opstheater-docs. releasechecklist.md will contains the basic steps that release manager needs to perform once the upgrade is finised to make sure that all opstheater components are working fine.
......
......@@ -2,34 +2,34 @@
For this release OpsTheater components will need to be upgraded manually. In the future we aim to automate as much of this as possible, all help is welcome!
* Gitlab will be upgraded from version 8.6 to 8.7
* Mattermost will be upgraded from version 2.1 to 2.2
* Percona server stays at 5.6.29
* Logstash stays at 2.1.1
* Kibana stays at 4.2.1
* Puppet from 4.4.0 to 4.4.2
* Foreman from 1.10.2 to 1.10.3
* Icinga 2 from 2.4.4 to 2.4.7
* Icinga web 2 from 2.2.0 to 2.2.3
* Filebeat from 1.2.0 to 1.2.2
* grafana stays at 2.5.0
Please see the release notes for a list of versions: https://gitlab.olindata.com/opstheater/opstheater/blob/1360740fc3baaad4fdcb719b8572ac58d0015845/RELEASENOTES.md
* Gitlab will be upgraded from version 8.6 to 8.7
* Mattermost will be upgraded from version 2.1 to 2.2
* Percona server stays at 5.6.29
* Logstash stays at 2.1.1
* Kibana stays at 4.2.1
* Puppet from 4.4.0 to 4.4.2
* Foreman from 1.10.2 to 1.10.3
* Icinga 2 from 2.4.4 to 2.4.7
* Icinga web 2 from 2.2.0 to 2.2.3
* Filebeat from 1.2.0 to 1.2.2
* grafana stays at 2.5.0
Please see the release notes for a list of versions: <https://gitlab.olindata.com/opstheater/opstheater/blob/1360740fc3baaad4fdcb719b8572ac58d0015845/RELEASENOTES.md>
## Steps
1. Disable puppet on all OpsTheater nodes
1. Disable puppet on all OpsTheater nodes
---
Login to the following servers one by one and disable puppet agent by command `puppet agent --disable`
* puppet.example.com
* icinga.example.com
* mysql.example.com
* gitlab.example.com
* elastic.example.com
* puppet.example.com
* icinga.example.com
* mysql.example.com
* gitlab.example.com
* elastic.example.com
2. Upgrade MySQL
2. Upgrade MySQL
---
No MySQL upgrade is needed this time, so we just need to upgrade the icinga, puppet and filebeat packages.
......@@ -51,7 +51,7 @@ icinga2-common-2.4.4-1.el7.centos.x86_64
puppet-agent-1.4.1-1.el7.x86_64
```
3. Upgrading elasticsearch
3. Upgrading elasticsearch
---
To upgrade Elasticsearch from 2.2 to 2.3 login to elasticsearch server and run the following commands:
......@@ -85,7 +85,7 @@ icinga2-common-2.4.4-1.el6.x86_64
puppet-agent-1.4.1-1.el6.x86_64
```
4. Upgrading icinga 2
4. Upgrading icinga 2
---
To upgrade Icinga 2 from 2.4.3 to 2.4.4 and Icinga web 2 from 2.1.2 to 2.2.0 login to the elastic server and run the following commands:
......@@ -132,10 +132,10 @@ icingaweb2-vendor-Parsedown-1.0.0-1.el7.centos.noarch
puppet-agent-1.4.1-1.el7.x86_64
```
5. Upgrading gitlab
5. Upgrading gitlab
---
Login on gitlab.example.com server do the following :
Login on gitlab.example.com server do the following :
```bash
[root@gitlab ~]# rpm -qa | egrep -i 'icinga2|puppet-agent|filebeat|gitlab' | sort
......@@ -168,10 +168,10 @@ icinga2-common-2.4.4-1.el7.centos.x86_64
puppet-agent-1.4.1-1.el7.x86_64
```
6. Upgrading puppetserver
6. Upgrading puppetserver
---
Login on puppet.example.com server do the following :
Login on puppet.example.com server do the following :
```bash
[root@puppet ~]# rpm -qa | egrep -i 'icinga2|puppet|filebeat' | sort
......@@ -209,25 +209,25 @@ puppetlabs-release-pc1-1.0.0-1.el7.noarch
puppetserver-2.3.1-1.el7.noarch
```
7. Deploy the puppetcode for OpsTheater 1.5.0 to your puppetmaster
7. Deploy the puppetcode for OpsTheater 1.5.0 to your puppetmaster
---
* on your development environment make sure you have the latest production branch of your puppet repository checked out
* merge the upstream opstheater 1.5 repo into the local repository
* merge conflicts and commit and push to your internal gitlab instance
* Login to Puppet Master server (puppet.example.com) and run r10k to deploy the latest puppet code on puppet master.
* on your development environment make sure you have the latest production branch of your puppet repository checked out
* merge the upstream opstheater 1.5 repo into the local repository
* merge conflicts and commit and push to your internal gitlab instance
* Login to Puppet Master server (puppet.example.com) and run r10k to deploy the latest puppet code on puppet master.
`r10k deploy environment production -pv`
8. Enable puppet for OpsTheater machines
8. Enable puppet for OpsTheater machines
---
Login to following servers one by one and test new puppet code
* puppet.example.com
* icinga.example.com
* mysql.example.com
* gitlab.example.com
* elastic.example.com
* puppet.example.com
* icinga.example.com
* mysql.example.com
* gitlab.example.com
* elastic.example.com
```bash
puppet agent --enable; puppet agent -t --noop; puppet agent --disable
......@@ -239,7 +239,7 @@ If the puppet agent runs in noop mode are succesful you can enable the agents an
puppet agent --enable; puppet agent -t
```
9. Test all the systems manually
9. Test all the systems manually
---
Perform the steps given in release checklist to make sure everything is working fine (https://gitlab.olindata.com/opstheater/opstheater-docs/blob/master/1.5/releasechecklist.md)
Perform the steps given in release checklist to make sure everything is working fine (<https://gitlab.olindata.com/opstheater/opstheater-docs/blob/master/1.5/releasechecklist.md>)
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment