[openstack-dev] conflicting names in python-openstackclient: could we have some exception handling please?
graham.hayes at hpe.com
Wed Oct 7 13:57:05 UTC 2015
On 07/10/15 14:42, Ryan Brown wrote:
> On 10/06/2015 05:15 PM, Thomas Goirand wrote:
>> 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 =
>> '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?
>> 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.
Is there a bug filed for it? I haven't seen this before and it seems to
be working for me locally :/
(I have openstackclient == 1.7.1 & designateclient == 1.5.0)
If we can find the issue we will try and get a fix out.
DNS as a Service
Advanced Network Services
HP Helion Cloud - Platform Services
GPG Key: 7D28E972
graham.hayes at hpe.com
M +353 87 377 8315
P +353 1 525 1589
More information about the OpenStack-dev