[openstack-dev] conflicting names in python-openstackclient: could we have some exception handling please?

Sean Dague sean at dague.net
Wed Oct 7 15:55:38 UTC 2015

On 10/07/2015 10:50 AM, Dean Troyer wrote:
> On Wed, Oct 7, 2015 at 8:39 AM, Ryan Brown <rybrown at redhat.com
> <mailto: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.

For the CLI, definitely agree. Balkanizing back to a namespace per
project is the wrong direction.

> 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 <mailto:dtroyer at gmail.com>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Sean Dague

More information about the OpenStack-dev mailing list