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