[openstack-dev] Allow defining a different auth strategy for different service providers.

Chmouel Boudjnah chmouel at chmouel.com
Wed Aug 1 13:26:08 UTC 2012


On Wed, Aug 1, 2012 at 3:08 PM, Monty Taylor <mordred at inaugust.com> wrote:
[...]
> Of course, I may be idealistic, but I imagine a world where Rackspace
> says "we run OpenStack" and HP says "we run OpenStack" and as a
> customer, I simply grab an openstack client and use it to connect to
> both providers.
> If my scripts have to _know_ that the Rackspace cloud is different and
> takes some silly extra header, then I'm having to put in branching logic
> in my orchestration code to handle the different clouds, and from a
> client perspective the fact that they are both openstack just became
> meaningless.

I totally agree with you I hate that we need to do that but I would
hate more that every providers HP/RAX or others provide their own fork
of the python binding if we are not helping them to plug themselves
into the current binding.

> What if we use pkg_resources entry points instead of a pure __import__?
> It would allow people to pretty easily distribute plugins ...
> I'll send a patch to your patch for you to look at

That would be great, hopefully service providers would be able to
distribute a simple plugin like that in PyPi and our openstack clients
would be able to pick it up.

I think AUTH_STRATEGY may be misleading with what we had in nova (but
tbh I am not sure what that variable was doing) I have started to
rename it to AUTH_SYSTEM if you have a better suggestion.

> Not to beat a dead horse here, but it would be STELLAR for there to be a
> discovery mechanism for this. If the call to client.Client could make a
> standard call that would return something that would indicate an ID key
> by which they would call their auth strategy, and then our client lib
> could look through any installed plugins that exist for one matching
> that key, so that we could remove the need for me to know that rax cloud
> needs rax auth strategy at invocation time.
> Or not. :)

yeah heu that would be nice so from an implementation POV you mean
having the user specify the os_username being like hp-REAL_USERNAME
and client.Client applying the  HP plugin if available to it ? this
may look ugly for our users.

Chmouel.



More information about the OpenStack-dev mailing list