[openstack-dev] [nova][cinder] can we deprecate the volume CLIs in novaclient?

Sean Dague sean at dague.net
Fri May 15 16:38:43 UTC 2015


On 05/15/2015 12:28 PM, Everett Toews wrote:
> 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, this is actually a different thing.

"nova volume ...."  does not talk to Nova's volume proxy, it goes
straight to cinder through the service catalog.

Deprecating this part of nova client is probably fine, but it should
have a lengthy deprecation cycle, as it's been like this for a very long
time. It feels like it won't go away before openstack client starts
taking hold anyway.

I think this raises a more important issue of Service Catalog
Standarization. The reason we're in a bind here has as much to do with
the fact that service catalog content isn't standardized for OpenStack
services. If so, having another cinder implementation in novaclient
wouldn't be such a bad thing, and not having to switch cli commands is
pretty handy (all hail our future osc overlords).

Fortunately, we're going to be talking about just this kind of problem
at Summit -
http://libertydesignsummit.sched.org/event/194b2589eca19956cb88ada45e985e29

	-Sean

-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list