Apparently in the window between switching from Jenkins to Zuul, some specs that were merged by zuul contained some format errors that Jenkins tests for but zuul does not. So now that we've switched back to Jenkins, and new specs trying to merge are getting test failures due to these other specs. This addresses the failure seen as well as a few other doc8 issues pointed out in case they cause issues as well. Change-Id: I92554c5481417e5d4e0cc931a1f6efdbee9b8733
4.0 KiB
Support create volume from backup
https://blueprints.launchpad.net/cinder/+spec/support-create-volume-from-backup
This blueprint proposes support for creating a volume from backup.
Problem description
Cinder has supported create volume from volume, snapshot and image. But when considering create volume from backup, users have to create a new volume first and then restore the volume with backup. Although we can restore backup without volume id, in that case Cinder will create a new volume in the background, but we still have some issues because we don't have any access to control the volume's az, volume type, size and many other attributes.
Use Cases
User can directly create volume from backup rather than create a new volume and then restore it.
Proposed change
This spec proposes to support create volume from backup, after this change users can directly create a new volume with backup id as below:
$ cinder create [size] --backup-id <id> [other_options]
Volume's size is equal to the backup's original volume size if size option is omitted.
Since we already introduced the generic backup implementation [1] for our existing volume drivers, it makes sense to add
this ability to our volume drivers, so when create volume from backup,
the request will be scheduled to the volume backend as normal, and first
we would try the vendor-specific create_volume_from_backup
method as below:
def create_volume_from_backup(self, volume, backup):
"""Creates a volume from a backup."""
raise NotImplementedError()
If the driver reports NotImplemented
or
NotSupported
, Cinder will directly create the raw volume at
the backend and then schedule the request to the backup service to
restore the volume with backup.
One of the differences between creating volume from snapshot and creating volume from backup is the latter could be time consuming, so we need to update the backup's status to prevent possible usages by other requests. For instance, when creating volume from backup the possible status for volume and backup are:
1. Volume: creating, available, error
2. Backup: restoring, available, error
Note: We will use 'creating' instead of 'restoring-backup' for the volume's transition status here in order not to expose the creating detail.
Alternatives
Keep using current restore API or create and restore mechanism to cover this use case.
Data model impact
None
REST API impact
Microversion bump is required for this change.
Cinder-client impact
Cinder-client will be updated to support create volume from backup.
Security impact
None
Notifications impact
None
Other end user impact
None
Performance Impact
When creating a volume from backup and the vendor-specific method does not exist, the creation process could take a little longer than a typical creation due to the restore action.
Other deployer impact
None
Developer impact
None
Implementation
Assignee(s)
Primary assignee:
- luqitao (qtlu@fiberhome.com)
- tommylikehu(tommylikehu@gmail.com)
Work Items
- Support create volume from backup in Cinder.
- Add related unit testcases.
- Add related tempest testcase.
- Update cinder-client and OSC.
Dependencies
Depends on generic backup implementation [1]
Testing
- Add unit tests to cover creating volume from backup.
Documentation Impact
Both API documentation and CLI documentation should be updated.