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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
