Open Stack

On Tue, Oct 6, 2015 at 4:15 PM, Thomas Goirand <zigo at debian.org> 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.
>

This creates a first-one-wins scenario that requires *-client install order
to be deterministic.   Or we need a registry of which API owns which object
namens (nouns), which would actually solve our problem today without any
changes.


> 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).
>

This is a problem with the implementation of the plugin, not with the
selection of command names.  Your experience with saharaclient and the fact
that editing setup.cfg did not help should confirm that.


> 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.
>

The conflicting command names is due to the way setuptools handles entry
points by default (I'm not sure if this can even be changed easily).  It
turns out that having multiple classes registered to a common command name
is useful, I have a plugin that does this intentionally in order to modify
the behaviour of an existing command (changes server create to add --ram,
--disk and --cpu to auto-select a flavor).

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151007/3bb3d7ee/attachment.html>