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:
parent
4a92c2ec8e
commit
cf355db0ed
@ -109,8 +109,8 @@ Plan your upgrade
|
||||
You can clean them up using ``cinder-manage service remove <binary> <host>``
|
||||
command.
|
||||
|
||||
* Assumed service upgrade order is cinder-api, cinder-scheduler, cinder-volume
|
||||
and finally cinder-backup.
|
||||
* Assumed service upgrade order is cinder-scheduler, cinder-volume,
|
||||
cinder-backup and finally cinder-api.
|
||||
|
||||
Rolling upgrade process
|
||||
'''''''''''''''''''''''
|
||||
@ -136,30 +136,15 @@ Before maintenance window
|
||||
During maintenance window
|
||||
"""""""""""""""""""""""""
|
||||
|
||||
1. cinder-api services should go first. 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. Cinder's internal mechanisms will make sure that new
|
||||
c-api will detect that it's running with older versions and will downgrade
|
||||
any communication.
|
||||
1. The first 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.
|
||||
|
||||
.. 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
|
||||
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
|
||||
3. 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
|
||||
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
|
||||
@ -183,9 +168,9 @@ During maintenance window
|
||||
it using ``host`` option in ``cinder.conf``), so both will be listening on
|
||||
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.
|
||||
|
||||
.. note::
|
||||
@ -206,6 +191,20 @@ During maintenance window
|
||||
upgrade strategy for cinder-backup should be more similar to how
|
||||
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
|
||||
""""""""""""""""""""""""
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user