On 05/14/2015 10:29 PM, Matt Riedemann 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.
I wrote this on the bug report, too, but I believe deprecating the
volume commands from novaclient is the appropriate solution. I think a
single 6 month deprecation cycle is appropriate.
Best,
-jay
__________________________________________________________________________
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
