Open Stack

On May 15, 2015, at 10:28 AM, John Griffith <john.griffith8 at gmail.com<mailto:john.griffith8 at gmail.com>> wrote:



On Thu, May 14, 2015 at 8:29 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com<mailto:mriedem at linux.vnet.ibm.com>> wrote:
This came up while talking about bug 1454369 [1].  This also came up at one point in kilo when we found out the volume CLIs in novaclient didn't work at one point and we broke the cells devstack exercises job because of it.

python-novaclient uses cinder API to handle the volume CLI rather than going to the nova volume API.  There are issues with this because novaclient needs a certain endpoint/service_type setup in the service catalog to support cinder v1/v2 APIs (whatever devstack sets up today).  novaclient defaults to volume (v1) and if you disable that in cinder then novaclient doesn't work because it's not using volumev2.

So like anyone might ask, why doesn't novaclient talk to nova volume APIs to do volume thingies and the answer is because the nova volume API doesn't handle all of the volume thingies like snapshots and volume types.

So I got to to thinking, why the hell are we still supporting volume operations via novaclient anyway?  Isn't that cinderclient's job?  Or python-openstackclient's job?  Can't we deprecate the volume CLIs in novaclient and tell people to use cinderclient instead since it now has version discovery [2] so that problem would be handled for us.

Since we have nova volume APIs maybe we can't remove the volume CLIs in novaclient, but could they be limited to just operations that the nova API supports and then we make novaclient talk to nova volume APIs rather than cinder APIs (because the nova API will talk to cinderclient which again has the version discovery done for us).

Or assuming we could deprecate the volume CLIs in novaclient, what would the timeline on deprecation be since it's not a server project with a 6 month release cycle?  I'm assuming we'd still have 6-12 months deprecation on a client like this because of all of the tooling potentially written around it.

[1] https://bugs.launchpad.net/python-novaclient/+bug/1454369
[2] https://review.openstack.org/#/c/145613/

​I can't speak for the nova folks, however i do think removing the volume calls from novaclient seems "ok".  It was always sort of left for compat I think, and not sure any of us really thought about just removing it.  At this point it probably just introduces confusion and as you're running into "problems".

Seems like a good plan, and somewhat less confusing.  On a side note, might be some other *things* in novaclient that we could look at as well, particularly around networking.  ​

FWIW, this is already underway in jclouds-land. After a lengthy deprecation period (still ongoing actually), we’ll be removing the Nova volume calls but obviously keeping the volume attachment stuff.

Both the Nova and Cinder calls have coexisted for over a year with documentation pointing from Nova to Cinder. The deprecation annotations handle emitting warnings for the deprecated calls to increase visibility.

Everett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150515/53b7bff9/attachment.html>