c9a55d852e
Adding SIGHUP handlers (by implementing reset from oslo.service) to cinder-scheduler, cinder-backup and cinder-volume that reset cached RPC version pins. This is to avoid the need to restart all the services when upgrade of the deployment is completed. Some changes go a little deep into the stack, because to reload all the pins we need to recreate <service>.rpcapi.<service>API objects that are stored in the memory. Please note that SIGHUP signal is handled by oslo.service only when service runs in daemon mode (without tty attached). To test this commit in DevStack you need to add "&" to the end of the command that starts the service. Situation is more complicated with the API service, so we're leaving it with restart required for now. In the deployments with HA cinder-api is typically behind a load balancer, so restarting individual nodes one-by-one should be easy. DocImpact: Add information on rolling upgrades procedures to the docs. Implements: blueprint rpc-object-compatibility Change-Id: I03ed74e17dc9a4b9aa2ddcfbeb36a106a0f035f8
17 lines
709 B
YAML
17 lines
709 B
YAML
---
|
|
features:
|
|
- Added RPC backward compatibility layer similar to the
|
|
one implemented in Nova. This means that Cinder
|
|
services can be upgraded one-by-one without breakage.
|
|
After all the services are upgraded SIGHUP signals
|
|
should be issued to all the services to signal them
|
|
to reload cached minimum RPC versions. Alternative
|
|
is of course restart of them. Please note that
|
|
cinder-api service doesn't support SIGHUP yet.
|
|
Please also take into account that all the rolling
|
|
upgrades capabilities are considered tech preview,
|
|
as we don't have a CI testing it yet.
|
|
upgrade:
|
|
- Starting from Mitaka release Cinder is having a tech
|
|
preview of rolling upgrades support.
|