openstack
/
cinder
Code Issues Proposed changes

Correct documented service upgrade order 

We had inconsistent service upgrade order information in our upgrade
documentation. This corrects the order to be consistent with our
recommended order of operations.

Change-Id: Ifa8ea98e494d3058ef1a29fee4ab9fa76149ce08
Closes-bug: #1738223
This commit is contained in:
Sean McGinnis 2017-12-14 15:07:16 -06:00
parent 4a92c2ec8e
commit cf355db0ed
1 changed files with 25 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
doc/source/upgrade.rst
View File

@ -109,8 +109,8 @@ Plan your upgrade
You can clean them up using ``cinder-manage service remove <binary> <host>`` You can clean them up using ``cinder-manage service remove <binary> <host>``
command. command.
* Assumed service upgrade order is cinder-api, cinder-scheduler, cinder-volume * Assumed service upgrade order is cinder-scheduler, cinder-volume,
and finally cinder-backup. cinder-backup and finally cinder-api.
Rolling upgrade process Rolling upgrade process
''''''''''''''''''''''' '''''''''''''''''''''''
@ -136,30 +136,15 @@ Before maintenance window
During maintenance window During maintenance window
""""""""""""""""""""""""" """""""""""""""""""""""""
1. cinder-api services should go first. In HA deployment you're typically 1. The first service is cinder-scheduler. It is load-balanced by the message
running them behind a load balancer (e.g. HAProxy), so you need to take one queue, so the only thing you need to worry about is to shut it down
service instance out of the balancer, shut it down, upgrade the code and gracefully (using ``SIGTERM`` signal) to make sure it will finish all the
dependencies, and start the service again. Then you can plug it back into requests being processed before shutting down. Then you should upgrade the
the load balancer. Cinder's internal mechanisms will make sure that new code and restart the service.
c-api will detect that it's running with older versions and will downgrade
any communication.
.. note:: 2. Repeat first step for all of your cinder-scheduler services.
You may want to start another instance of older c-api to handle the load 3. Then you proceed to upgrade cinder-volume services. The problem here is that
while you're upgrading your original services.
2. Then you should repeat first step for all of the cinder-api services.
3. Next service is cinder-scheduler. It is load-balanced by the message queue,
so the only thing you need to worry about is to shut it down gracefully
(using ``SIGTERM`` signal) to make sure it will finish all the requests
being processed before shutting down. Then you should upgrade the code and
restart the service.
4. Repeat third step for all of your cinder-scheduler services.
5. Then you proceed to upgrade cinder-volume services. The problem here is that
due to Active/Passive character of this service, you're unable to run due to Active/Passive character of this service, you're unable to run
multiple instances of cinder-volume managing a single volume backend. This multiple instances of cinder-volume managing a single volume backend. This
means that there will be a moment when you won't have any cinder-volume in means that there will be a moment when you won't have any cinder-volume in
@ -183,9 +168,9 @@ During maintenance window
it using ``host`` option in ``cinder.conf``), so both will be listening on it using ``host`` option in ``cinder.conf``), so both will be listening on
the same message queue and will accept the same messages. the same message queue and will accept the same messages.
6. Repeat fifth step for all cinder-volume services. 4. Repeat third step for all cinder-volume services.
7. Now we should proceed with (optional) cinder-backup services. You should 5. Now we should proceed with (optional) cinder-backup services. You should
upgrade them in the same manner like cinder-scheduler. upgrade them in the same manner like cinder-scheduler.
.. note:: .. note::
@ -206,6 +191,20 @@ During maintenance window
upgrade strategy for cinder-backup should be more similar to how upgrade strategy for cinder-backup should be more similar to how
cinder-volume is upgraded. cinder-volume is upgraded.
6. cinder-api services should go last. In HA deployment you're typically
running them behind a load balancer (e.g. HAProxy), so you need to take one
service instance out of the balancer, shut it down, upgrade the code and
dependencies, and start the service again. Then you can plug it back into
the load balancer.
.. note::
You may want to start another instance of older c-api to handle the load
while you're upgrading your original services.
7. Then you should repeat step 6 for all of the cinder-api services.
After maintenance window After maintenance window
"""""""""""""""""""""""" """"""""""""""""""""""""