From cf355db0ed357fb8387206735f4ea2cb717751a8 Mon Sep 17 00:00:00 2001 From: Sean McGinnis Date: Thu, 14 Dec 2017 15:07:16 -0600 Subject: [PATCH] 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 --- doc/source/upgrade.rst | 51 +++++++++++++++++++++--------------------- 1 file changed, 25 insertions(+), 26 deletions(-) diff --git a/doc/source/upgrade.rst b/doc/source/upgrade.rst index 92351552fae..562ad91ee64 100644 --- a/doc/source/upgrade.rst +++ b/doc/source/upgrade.rst @@ -109,8 +109,8 @@ Plan your upgrade You can clean them up using ``cinder-manage service remove `` 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 """"""""""""""""""""""""