e7b8d4bb01
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
166 lines
4.0 KiB
ReStructuredText
166 lines
4.0 KiB
ReStructuredText
..
|
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
|
License.
|
|
|
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
|
|
|
=================================
|
|
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:
|
|
|
|
.. code-block:: bash
|
|
|
|
$ 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:
|
|
|
|
.. code-block:: python
|
|
|
|
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:
|
|
|
|
1. luqitao (qtlu@fiberhome.com)
|
|
2. 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.
|
|
|
|
References
|
|
==========
|
|
|
|
* _`[1]`: https://github.com/openstack/cinder-specs/blob/master/specs/queens/generic-backup-implementation.rst
|