<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 20, 2016 at 1:00 PM, Hongbin Lu <span dir="ltr"><<a href="mailto:hongbin.lu@huawei.com" target="_blank">hongbin.lu@huawei.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-CA">
<div class="gmail-m_6136922083558136470WordSection1">
<p class="MsoNormal"> <br></p><p class="MsoNormal"><u></u></p>
<p class="MsoNormal">$ openstack objectstore container <action> <args><u></u><u></u></p>
<p class="MsoNormal">$ openstack container container <action> <args><u></u><u></u></p>
<p class="MsoNormal">$ openstack secret container <action> <args><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thoughts?</p></div></div></blockquote><div><br></div><div>This is the closest thing I can see that's somewhat reasonable - with the obvious exception of "container container <action>" - which is pretty gross.</div><div><br></div><div>Here's the best list I could find of what's going on now:<div><br></div><div><a href="http://docs.openstack.org/developer/python-openstackclient/command-list.html">http://docs.openstack.org/developer/python-openstackclient/command-list.html</a></div></div><div><br></div><div>The collision of top-level resource names is not new.  You see stuff like "volume create" & "server create" - but also "volume backup create" & "server backup create"- which is an obvious pattern to replicate for disambiguating top level name conflicts with similarly named (sub?)-resources between services - except apparently in an effort to keep things flat no one saw it coming with a name like "container".</div><div><br></div><div>But IMHO an object-store "container" is not a top level OpenStack resource, is it?  I would think users would be happy to dump stuff into the object store using "object create" - and reasonably expect to use "object container create" to create a container *for their objects*?  This isn't a generic OpenStack "container" - you can't use this generic "container" for anything except objects?  Oddly, this pattern is already in use with the pre-existing "object store account" command?!</div><div><br></div><div>Is it really already too late to apply some sane organization to the object store commands in the openstack-cli and make room in the command namespace for a top level OpenStack resource to manage a linux-containers' service?  Because of backwards compatibility issues?</div><div><br></div><div>-Clay</div></div></div></div>