openstack/cinder
Code Issues Proposed changes
4566b6f550
cinder/releasenotes/notes/scaling-backup-service-7e5058802d2fb3dc.yaml

9 lines
293 B
YAML
Raw Normal View History

Scalable backup service - Liberty compatibility 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
2016-02-19 09:28:36 +01:00
---
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.
Copy Permalink