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.griffi...@gmail.com
<mailto:john.griffi...@gmail.com>> wrote:
On Thu, May 14, 2015 at 8:29 PM, Matt Riedemann
<mrie...@linux.vnet.ibm.com <mailto:mrie...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
