Bug 1267948

Summary:	[RFE][cinder] Retrieve Supported Volume Type Extra Specs
Product:	Red Hat OpenStack	Reporter:	Sean Cohen <scohen>
Component:	openstack-cinder	Assignee:	Eric Harney <eharney>
Status:	CLOSED ERRATA	QA Contact:	lkuchlan <lkuchlan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0 (Kilo)	CC:	eharney, jschluet, sgotliv, yeylon
Target Milestone:	beta	Keywords:	FutureFeature, OtherQA
Target Release:	8.0 (Liberty)
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/cinder/+spec/get-volume-type-extra-specs
Whiteboard:
Fixed In Version:	openstack-cinder-7.0.0-2.el7ost	Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-07 21:10:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Sean Cohen 2015-10-01 12:41:28 UTC

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.

Comment 3 lkuchlan 2016-02-03 10:33:52 UTC

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'} |
+--------------------+---------------------------------------------------------------------------------------------------+

Comment 5 errata-xmlrpc 2016-04-07 21:10:16 UTC

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