Open Stack

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/

-- 

Thanks,

Matt Riedemann