Open Stack

On 07/10/15 14:42, Ryan Brown wrote:
> 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.

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.



-- 
Graham Hayes
Software Engineer
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
Dublin,
Ireland

HP