[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
http://dague.net
More information about the OpenStack-dev
mailing list