<div style="white-space:pre-wrap">Duncan,<br><br>Agreed, but the OSC team is concerned about unnecessarily adding API names into commands as much as the Cinder team wishes to make it clearer which commands belong to our component. This is where we need to keep this discussion open with the OSC team to find a good common ground. I am hoping to have Slade Baumann and Jacob Gregor work this issue actively with Sheel. We need to pull you in as well given your views on this. I will make sure they keep you in the loop.<br><br>Jay</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 5, 2016 at 10:24 AM Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com">duncan.thomas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What about commands the become ambiguous in the future? I doubt there are many operations or objects that are unique to Cinder - backup, snapshot, transfer, group, type - these are all very much generic, and even if they aren't ambiguous now, they might well become so in future...<br></div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 April 2016 at 17:15, Jay Bryant <span dir="ltr"><<a href="mailto:jsbryant@electronicjungle.net" target="_blank">jsbryant@electronicjungle.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="white-space:pre-wrap">All,<br><br>Just to document the discussion we had during the OSC IRC meeting last week: I believe the consensus we reached was that it wasn't appropriate to pretend "volume" before all Cinder commands but that it would be appropriate to move in that direction to for any commands that may be ambiguous like "snapshot". The cinder core development team will start working with the OSC development teams to address such commands and move them to more user friendly commands and as we move forward we will work to avoid such confusion in the future.<span><font color="#888888"><br><br>Jay</font></span></div><br><div class="gmail_quote"><div><div><div dir="ltr">On Mon, Mar 28, 2016 at 1:15 PM Dean Troyer <<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Mar 27, 2016 at 6:11 PM, Mike Perez <span dir="ltr"><<a href="mailto:thingee@gmail.com" target="_blank">thingee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 00:40 Mar 28, Jordan Pittier wrote:<br>
> I am going to play the devil's advocate here but why can"t<br>
> python-openstackclient have its own opinion on the matter ? This CLI seems<br>
> to be for humans and humans love names/labels/tags and find UUIDS hard to<br>
> remember. Advanced users who want anonymous volumes can always hit the API<br>
> directly with curl or whatever SDK.<br>
<br>
</span>I suppose it could, however, names are not unique.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Names are not unique in much of OpenStack. When ambiguity exists, we exit with an error.</div><div><br></div><div>Also, this works to produce a volume with no name should you absolutely require it:</div><div><br></div><div>openstack volume create --size 10 ""</div><div><br></div><div><br></div><div>dt </div></div></div></div><div dir="ltr"><div class="gmail_extra">-- <br><div><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div></div></div><span>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</span></blockquote></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br></div><div class="gmail_extra">-- <br><div><div dir="ltr"><div>-- <br>Duncan Thomas</div></div></div>
</div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><div style="white-space:pre-wrap"><br></div>