Open Stack

On 10/06/2015 05:15 PM, Thomas Goirand wrote:
> Hi,
>
> tl;dr: let's add a exception handling so that python-*client having
> conflicting command names isn't a problem anymore, and "openstack help"
> always work as much as it can.

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.

Sharing a flat namespace is a recipe for pain with a growing number of 
projects. Devs and users are unlikely to use every project, they 
probably won't notice conflicts naturally except in cases like horizon.

If we look over the fence at AWS, you'll note that their nice unified 
CLI that stops the non-uniform `awk` bloodshed is namespaced.

- aws s3 ...
- aws cloudformation ...
- aws ec2 ...

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.

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

Namespaces are one honking great idea -- let's do more of those!

> Longer version:
>
> This is just a suggestion for contributors to python-openstackclient.
>
> I saw a few packages that had conflicts with the namespace of others
> within openstackclient. To the point that typing "openstack help" just
> fails. Here's an example:
>
> # openstack help
> [ ...]
>    project create  Create new project
>    project delete  Delete project(s)
>    project list   List projects
>    project set    Set project properties
>    project show   Display project details
> Could not load EntryPoint.parse('ptr_record_list =
> designateclient.v2.cli.reverse:ListFloatingIPCommand')
> 'ArgumentParser' object has no attribute 'debug'
>
> This first happened to me with saharaclient. Lucky, upgrading to latest
> version fixed it. Then I had the problem with zaqarclient, which I fixed
> with a few patches to its setup.cfg. Then now designate, but this time,
> patching setup.cfg doesn't seem to cut it (ie: after changing the name
> of the command, "openstack help" just fails).
>
> Note: I don't care which project is at fault, this isn't the point here.
> The point is that command name conflicts aren't handled (see below)
> which is the problem.

+1, this isn't a problem specific to any project, it's systemic with 
flat namespacing.

> With Horizon being a large consumer of nearly all python-*client
> packages, removing one of them also removes Horizon in my CI which is
> not what I want to (or can) do to debug a tempest problem. End of the
> story: since Liberty b3, I never could have "openstack help" to work
> correctly in my CI... :(

O.O That's unfortunate.

> Which leads me to write this:
>
> Since we have a very large amount of projects, with each and everyone of
> them adding new commands to openstackclient, I would really nice if we
> could have some kind of checks to make sure that conflicts are either 1/
> not possible or 2/ handled gracefully.

To your (1) we could have a gate job that installs all the clients and 
fails on conflicts.

The downside of doing that without addressing the namespace problem is 
that there will be inconsistent conventions everywhere. Zaqar will have 
"openstack queue ...." but "openstack message flavor ..." which creates 
the sort of confusion a unified client is supposed to avoid.

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

> Your thoughts?
> Cheers,
>
> Thomas Goirand (zigo)
>
> P.S: It wasn't the point of this message, but do we have a fix for
> designateclient? It'd be nice to have this fixed before Liberty is out.

-- 
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.