This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1267948 - [RFE][cinder] Retrieve Supported Volume Type Extra Specs
[RFE][cinder] Retrieve Supported Volume Type Extra Specs
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-cinder (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
medium Severity medium
: beta
: 8.0 (Liberty)
Assigned To: Eric Harney
lkuchlan
https://blueprints.launchpad.net/cind...
: FutureFeature, OtherQA
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-01 08:41 EDT by Sean Cohen
Modified: 2016-04-26 14:34 EDT (History)
4 users (show)

See Also:
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 17:10:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenStack gerrit 201243 None None None Never

  None (edit)
Description Sean Cohen 2015-10-01 08:41:28 EDT
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 05:33:52 EST
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 17:10:16 EDT
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

Note You need to log in before you can comment on or make changes to this bug.