05a516da01
To support rolling upgrades we need to make sure that Mitaka's services are running fine with Liberty's. It gets complicated with backups as we've strongly reworked them. Main difference is that Mitaka c-bak can handle backup/restore of any volume and Liberty was restricted to operate only on volumes placed on the same node. Now when running in version heterogeneous environment we need to use old way of backup jobs scheduling and switch to new one (round robin) only when everything is running Mitaka. This commit implements that by adding a dummy backup RPC API version (1.3) that marks the beginning of scalable backups era. Jobs are scheduled the new way only if every c-bak reports that (or higher) version. There are also small changes to volume.rpcapi - to fail fast if some c-vol services aren't supporting new calls required by scalable backups feature. This allows us to error out backups with proper message when upgrade was done in an improper way (in Mitaka we require c-vols to be upgraded before c-baks). This commit also includes small changes to CinderObjectSerializer to block tries to "forwardport" an object when sending it over RPC. If a service receives an older object it should handle it explicitly. Related-Blueprint: scalable-backup-service Co-Authored-By: Michal Dulko <michal.dulko@intel.com> Change-Id: I45324336ba00726d53cfa012e8bd498868919a8c
9 lines
293 B
YAML
9 lines
293 B
YAML
---
|
|
features:
|
|
- cinder-backup service is now decoupled from
|
|
cinder-volume, which allows more flexible scaling.
|
|
upgrade:
|
|
- As cinder-backup was strongly reworked in this
|
|
release, the recommended upgrade order when executing
|
|
live (rolling) upgrade is c-api->c-sch->c-vol->c-bak.
|