volume_type key still exists in share_type APIs

[Goutham Pacha Ravi]

volume_types are not used by any client that we know of and this should really be removed with micro versions.

sample cURL response:

DEBUG (httpclient:201) RESP: [200] {'Content-Length': '555', 'X-Compute-Request-Id': 'req-699ec076-00dc-445f-a9b4-92228ecccdaf', 'Vary': 'X-OpenStack-Manila-API-Version', 'Connection': 'close', 'X-Openstack-Manila-Api-Version': '2.15', 'Date': 'Fri, 27 May 2016 15:08:07 GMT', 'Content-Type': 'application/json'}
RESP BODY: {"share_type": {"required_extra_specs": {"driver_handles_share_servers": false}, "share_type_access:is_public": true, "extra_specs": {"snapshot_support": "True", "driver_handles_share_servers": "False"}, "id": "ab675976-f966-4ff6-8d1b-7be0aacae1a9", "name": "my_share_type_4"}, "volume_type": {"required_extra_specs": {"driver_handles_share_servers": false}, "share_type_access:is_public": true, "extra_specs": {"snapshot_support": "True", "driver_handles_share_servers": "False"}, "id": "ab675976-f966-4ff6-8d1b-7be0aacae1a9", "name": "my_share_type_4"}}

[Goutham Pacha Ravi (gouthamr)]

Working on this. Thanks!

[Tom Barron (tpb)]

Goutham are you still working on this or should we un-assign?

[Jason Grosso (jgrosso)]

Goutham is this still an active issue you are working on?

[Goutham Pacha Ravi (gouthamr)]

Sorry Tom and Jason, I have a draft patch downstream, but ran into troubles with respect to the JSON object parsing that we do in the manila-tempest-plugin. I'll prefer to un-assign and discuss if anyone is motivated to contribute this fix.

[Goutham Pacha Ravi (gouthamr)]

I'm also marking this a Wishlist bug, since it is just going to make the share types API cleaner, and will not remove or add any information that is critical to consumers.

[Goutham Pacha Ravi (gouthamr)]

If someone wants to tackle this bug, the following would be the approach:

1) Bump the API Microversion
2) In the new API microversion, stop sending the "volume_type" JSON object in the response.
3) Fix manila-tempest-plugin to stop expecting the "volume_type" JSON object when testing the newer microversion, but add a test to explicitly expect the "volume_type" JSON object in older Microversions.

Relevant literature:

[1] https://developer.openstack.org/api-ref/shared-file-system/#share-types
[2] https://docs.openstack.org/manila/latest/contributor/api_microversion_dev.html
[3] https://github.com/openstack/manila-tempest-plugin/blob/b087b3093b26ce069b57dca91acb7f1b186cac6f/manila_tempest_tests/services/share/v2/json/shares_client.py#L898-L935 (Currently the API response object contains two top level keys, so _parse_resp() ignores these objects and lets the calling methods parse the share type out on their own. This will fail when the API stops sending the top level key/object: "volume_type")