Problem description The current implementation of volume type extra specs management process in Horizon and the cinder client are error-prone. Operators manage extra specs without having guidance on what capabilities are possible with a backend. Without knowing the capabilities, the operator doesn’t know what the possible extra spec key/values are. Today operators have to make sure they’re reading the right documentation that corresponds to the version of their storage backend. Documentation can become out of date with their volume driver. It would be more convenient, and a better user experience if the operator was able to ask Cinder for the capabilities of the current deployed storage backends, instead of having to guess. Use Cases As an operator, I want to get a list of the capabilities for my deployed storage backends in Cinder. With these capabilities, I have keys and possible values that can be used within a volume type’s extra specs. Potentially with the API endpoint, Horizon could use it to improve the GUI for managing extra specs. Proposed change Cinder volume drivers to implement a new method get_capabilities, which will return a dictionary of supported capabilities from the storage backend. The dictionary will include some brief information about the backend, and capabilities that correspond to extra spec keys and values. Features like create volume, create snapshots, etc are considered minimum features [1]. Unlike well defined keys [2], minimum features are required to implement. With well defined keys, drivers just need to report if the capability is not supported. If the backend has some vendor unique capabilities, the backend driver can also define vendor unique keys for supported capabilities.
Tested using: python-cinder-7.0.1-5.el7ost.noarch openstack-cinder-7.0.1-5.el7ost.noarch python-cinderclient-1.4.0-1.el7ost.noarch [stack@instack ~]$ cinder get-capabilities overcloud-controller-0.localdomain@Netapp1 +---------------------+-----------------------------------------------------------------------+ | Volume stats | Value | +---------------------+-----------------------------------------------------------------------+ | description | None | | display_name | None | | driver_version | 1.0.0 | | namespace | OS::Storage::Capabilities::overcloud-controller-0.localdomain@Netapp1 | | pool_name | None | | storage_protocol | iSCSI | | vendor_name | NetApp | | visibility | None | | volume_backend_name | Netapp1 | +---------------------+-----------------------------------------------------------------------+ +--------------------+---------------------------------------------------------------------------------------------------+ | Backend properties | Value | +--------------------+---------------------------------------------------------------------------------------------------+ | compression | {u'type': u'boolean', u'description': u'Enables compression.', u'title': u'Compression'} | | qos | {u'type': u'boolean', u'description': u'Enables QoS.', u'title': u'QoS'} | | replication | {u'type': u'boolean', u'description': u'Enables replication.', u'title': u'Replication'} | | thin_provisioning | {u'type': u'boolean', u'description': u'Sets thin provisioning.', u'title': u'Thin Provisioning'} | +--------------------+---------------------------------------------------------------------------------------------------+
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0603.html