Open Stack

On 5/15/2015 9:38 AM, Sean Dague wrote:
> 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
>

Here is the change for those following along at home:

https://review.openstack.org/#/c/185141/

-- 

Thanks,

Matt Riedemann