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

Monty Taylor mordred at inaugust.com
Wed Aug 1 13:08:28 UTC 2012



On 08/01/2012 05:11 AM, Chmouel Boudjnah wrote:
> Hi everyone,
> 
> Some service provider implement a bit differently the keystone auth by using the
> extension mechanism.

While I think that having extensions in keystone are an excellent idea,
I've got to say that implementing an extension that requires someone to
do something special on their first connection is a terrible design,
because it doesn't allow for discover-ability. Especially in this case,
where the extra header that has to be sent isn't even different or
useful information that couldn't be gained from RAX by the standard headers.

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.

> Historically for RAX we had this kind of hack :
> 
> https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L297
> 
> which obviously is not right to have in the main client and monty has
> sent a review to removed it :
> 
> https://review.openstack.org/#/c/10497/
> 
> I have started implement a plugin mechanism to allow different auth to
> be passed and would like to be done in a common way since we will need
> that for swiftclient as well.

Yay for plugins!

> I have started an implementation example here :
> 
> https://github.com/chmouel/python-novaclient/commit/3e4b4d367071ec251355fd5a15367c9028e7acca
> 
> And here is an example plugin for RAX 2.0 :
> 
> def authenticate(cls):
>     """Authenticate against the Rackspace auth service."""
>     body = {"auth": {
>         "RAX-KSKEY:apiKeyCredentials": {
>             "username": cls.user,
>             "apiKey": cls.password,
>             "tenantName": cls.projectid}}}
>     cls._authenticate(cls.auth_url, body)
> 
> assuming you have this in a file in your PYTHON_PATH named :
> 
> openstack_client_auth_rackspace2_0.py

I love the idea of pluggable auth strategy (ok, I obviously hate that we
need it, but if we do, I love the idea)

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

> and connect with :
> 
> from novaclient.v1_1 import client
> cnx = client.Client("user", "password", "notneeded",
>                     "https://lon.identity.api.rackspacecloud.com/v2.0",
>                     auth_strategy="rackspace2_0")
> 
> it would properly auth to RACK2.0 cloud[1].

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

> This would allow for service providers provider providing only this
> file for all the clients to use to authenticate.
> 
> What do you think?
> 
> Regards,
> Chmouel.
> 
> [1] Obviously this should goes along with a env variable.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list