<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 7, 2015 at 8:39 AM, Ryan Brown <span dir="ltr"><<a href="mailto:rybrown@redhat.com" target="_blank">rybrown@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Standardizing on "openstack <project> <noun[s]> verb" would likely be the best solution for both the immediate problem and for the broader "naming stuff" issue.<br></blockquote><div><br></div><div>This is the approach that a number of plugins are taking.  I have STRONGLY recommended that the project name not be used, OSC never uses project names in a user-visible way.  Some plugins do it anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">A flat namespace was a mostly-fine idea when all integrated projects were expected to put their CLI in-tree in openstackclient. There were reviews, and discussions about what noun belonged to whom.<br></blockquote><div><br></div><div>I wish there had been more of that.  You'd be surprised how little there actually has been...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Noun conflict will only get worse: lots of projects will share words like stack, domain, user, container, address, and so on.<br></blockquote><div><br></div><div>This is one reason multiple-word object names are possible.  For example, we've just merged commands to support the object store 'account' functions and used 'object store account' for those commands because we felt that 'account' is too generic.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">A central reservation process for nouns won't really scale, but namespacing will because we *already* namespace projects.</blockquote><div><br></div><div>I believe it will scale far enough to encomapss the realistic possibilites of putting everything under the top-level 'openstack' command.  I think that is the assumption that we need to be addressing.  As you said, it worked when we started 4 years ago, but even then there were conflicts. We are discussing alternatives that include multiple top-level commands.  But we need to get input from actual users who are not OpenStack devs on this and do not have the pre-concieved notions of this-api and that-api to the extent that those of us in the project do.  This is just getting underway, and will be a summit topic.</div></div><div><div><br class="">Users should not have to know or care which API implements something.</div></div><div><br></div><div>I am beginning to regret giving up the command name control as it is re-creating the situation we had with the original CLIs and the lack of consistency.</div><div><br></div><div>Also I want to add that the philosophy of OpenStackClient is not to simply accept everything that the API declares as the CLI and stop there, but to make the operations simple and meaningful for the users.  We have abstracted some API bits and flat out changed others to do this.  </div><div><br></div><div>dt</div><div><br></div><div>"The 'C' in OSC == 'consistent'."</div><div class="gmail_extra"><br></div>-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>