Cinder currently has the ability to take over the management of existing volumes and snapshots (“manage existing”) and to relinquish management of volumes and snapshots (“unmanage”). The API to manage an existing volume takes a reference, which is a driver-specific string that is used to identify the volume on the storage backend. This process is currently confusing and error prone. This spec’s purpose is to detail APIs for listing volumes and snapshots available for management to make this flow more user-friendly. Allowing the listing of available volumes/snapshots will allow for the creation of an easy-to-use GUI to migrate existing volumes to a new OpenStack environment, or to recover in the case the Cinder database is lost.
There is no Cinder API to list the volumes and snapshots available for managing, nor to know what reference string to use without referring to driver-specific documentation. This means that an admin must query the storage backend, get the appropriate references, and put them into the appropriate Cinder API. Without the proposed APIs this flow is confusing and error-prone.
Having Cinder manage an existing block storage volume or snapshot, using only Cinder APIs and without referring to external driver documentation.
Add new APIs to: 1) list volumes available for management in a given pool. 2) list snapshots available for management in a given pool.
The APIs would return information regarding the volumes/snapshots, provided by the driver. In addition, for each resource, an indication will be provided if it is safe to manage it. The cinder-volume manager will call the appropriate driver to get a list of resources. For each, the driver will return a safety indication, which includes if a volume is attached, or a Cinder ID if it suspects the resource is already managed by Cinder. The manager will look up any resources suspected already in use in the DB and mark them as not safe (this avoids the driver accessing the DB).
A list of items will be returned to the user, consisting of:
For listing snapshots, return these additional fields:
Leave as is.
Add two additional API extensions.
Cinder currently has the ability to create objects in the storage pool, and view or modify those objects. This allows the admin to view volumes not created by Cinder. On the other hand, the admin can take the storage credentials that Cinder has and perform the action on the storage backend itself, so there is no real impact.
Driver maintainers can add the two new calls to bring this functionality to their drivers.
I propose that list_manageable be added as a new GET action on the os-volume-manage Cinder extension. It would be separately specifiable in Cinder’s policy.json file to restrict access appropriately (default being admin_api).
There would be new RPC calls to cinder-volume which would call two new driver APIs (list_manageable_volumes and list_manageable_snapshots). I will implement the LVM driver code as well, as a reference implementation.
Standard unit tests and manual testing, as well as tempest test for these proposed APIs, as well as manage and unmanage.
The new APIs will be documented.