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.ha...@hpe.com M +353 87 377 8315 P +353 1 525 1589 Dublin, Ireland HP __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev