From 34d6d06642283ce6be36897baf9e536cb53c3d92 Mon Sep 17 00:00:00 2001
From: Rajat Dhasmana <rajatdhasmana@gmail.com>
Date: Mon, 2 Nov 2020 14:50:30 -0500
Subject: [PATCH] Support storing volume format info

blueprint add-support-store-volume-format-info

Change-Id: I0ba7acc803c53adef6249deac80256a6c3283083
---
 specs/wallaby/store-volume-format-info.rst | 154 +++++++++++++++++++++
 1 file changed, 154 insertions(+)
 create mode 100644 specs/wallaby/store-volume-format-info.rst

diff --git a/specs/wallaby/store-volume-format-info.rst b/specs/wallaby/store-volume-format-info.rst
new file mode 100644
index 00000000..435c058f
--- /dev/null
+++ b/specs/wallaby/store-volume-format-info.rst
@@ -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