Open Stack

On Wed, Oct 7, 2015 at 8:39 AM, Ryan Brown <rybrown at redhat.com> wrote:

> 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.
>

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.


> 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.
>

I wish there had been more of that.  You'd be surprised how little there
actually has been...


> Noun conflict will only get worse: lots of projects will share words like
> stack, domain, user, container, address, and so on.
>

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.


> A central reservation process for nouns won't really scale, but
> namespacing will because we *already* namespace projects.


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.

Users should not have to know or care which API implements something.

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.

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.

dt

"The 'C' in OSC == 'consistent'."

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151007/9b46456f/attachment.html>