<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 14, 2015 at 8:29 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
[1] <a href="https://bugs.launchpad.net/python-novaclient/+bug/1454369" target="_blank">https://bugs.launchpad.net/python-novaclient/+bug/1454369</a><br>
[2] <a href="https://review.openstack.org/#/c/145613/" target="_blank">https://review.openstack.org/#/c/145613/</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">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".</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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. </div><br></div></div>