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.
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. 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... :( 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. 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. __________________________________________________________________________ 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