Support storing volume format info
blueprint add-support-store-volume-format-info Change-Id: I0ba7acc803c53adef6249deac80256a6c3283083
This commit is contained in:
parent
873135ff05
commit
34d6d06642
154
specs/wallaby/store-volume-format-info.rst
Normal file
154
specs/wallaby/store-volume-format-info.rst
Normal file
@ -0,0 +1,154 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==================================
|
||||
Store volume format info in Cinder
|
||||
==================================
|
||||
|
||||
https://blueprints.launchpad.net/cinder/+spec/add-support-store-volume-format-info
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Currently, there are several filesystem-based drivers in Cinder which rely
|
||||
on auto detection of formats. Cinder does not store the actual format of
|
||||
volume and supposes all volumes are "raw" format.
|
||||
|
||||
One of such problems is seen when using glance cinder store with nfs as
|
||||
cinder backend and the file to be copied is a qcow2 image. When performing
|
||||
the extend operation, qemu-img uses the resize command which detects
|
||||
the volume format as qcow2 by reading the image's qcow2 header written into
|
||||
the volume. This leads to unsuccessful creation of the image.
|
||||
This is a problem because current code depends on auto detection of format
|
||||
and if the user has written a qcow2 image into the volume, the driver thinks
|
||||
it is a qcow2 volume (rather than qcow2 image stored in a raw volume) hence
|
||||
causing complication.
|
||||
Thus we need to store format info instead of auto detection.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
The "format" info will be added to "volume_admin_metadata" of volumes.
|
||||
The "format" will be only set / updated for filesystem-based drivers, other
|
||||
drivers will not contain this metadata.
|
||||
The "format" field will be created by FS drivers at the time of volume creation
|
||||
and is set to the format which the driver is configured to use.
|
||||
The "format" info will be returned in the attachment get API in the
|
||||
connection_info dict.
|
||||
When cloning a volume, this field will be updated in the new volume's metadata.
|
||||
For existing volumes, we check if format exists in admin_metadata and if not,
|
||||
we can perform ``qemu-img info`` to get the format and store it in the
|
||||
admin_metadata at that point.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Some of the fs type driver uses "qemu-img info" command to judge
|
||||
the format of volume. However, this auto-detection method has many possible
|
||||
error / exploit vectors. Because if the beginning content of a "raw" volume
|
||||
happens to be a "qcow2" disk, auto detection method will judge this volume to be
|
||||
a "qcow2" volume wrongly. This is the same issue which cases glance to fail
|
||||
an image create operation when using cinder as a store.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
For volumes on filesystem-based drivers, there will be a related record in
|
||||
volume_admin_metadata table. For this record, the key column is "format" and
|
||||
the value is the volume's format in volume_admin_metadata table.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
The "format" info will returned in attachment get API::
|
||||
|
||||
/v3/{project_id}/attachments/{attachment_id}
|
||||
|
||||
{
|
||||
"attachment": {
|
||||
"id": "3b8b6631-1cf7-4fd7-9afb-c01e541a073c",
|
||||
...
|
||||
"connection_info": {
|
||||
"format": "raw",
|
||||
...
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
Implements the proper/complete fix for bug 1350504.
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
Fixes problem where a user can cause a volume to become inoperable
|
||||
by writing a qcow2 header into it.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
whoami-rajat
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
To support this feature, the work items are:
|
||||
|
||||
* Store format info in ``volume_admin_metadata`` table when creating or
|
||||
cloning a volume in fs type drivers.
|
||||
* Modify volume format when doing a snapshot delete (blockRebase) operation
|
||||
on an attached volume.
|
||||
* Pass format info when doing an extend operation.
|
||||
* Return format field in the attachment get API in connection_info dict.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Related unit and functional tests.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Add documentation regarding the format field visible in the attachment get API
|
||||
for fs drivers.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
None
|
Loading…
x
Reference in New Issue
Block a user