Open Stack

Hey Steve,

Welcome to the client consolidation bandwagon :-)

We started on sorting some of this in the summit before last, and while we didn't make as much progress as we'd like, Dean and Doug did excellent work on getting to some common agreement on how the flows should work, documenting those out, and normalizing the CLI patterns. At this past summit, we reconvened and agreed it all still needs work. See: https://launchpad.net/python-openstackclient for the launchpad project that we've been using to track and consolidate the progress on this kind of effort.

Also immediately check out  http://wiki.openstack.org/UnifiedCLI, and http://wiki.openstack.org/UnifiedCLI/Authentication which document exactly what you're talking about. 

Keystone also just landed some large updates into the trunk of keystoneclient that should make it much easier to use as well - and to be usable by other clients. Glanceclient was the first to start using keystoneclient to deal with the auth pieces under the covers, and on learning how much of a pain that was, I started working on the client changes that just landed. (those changes haven't yet been released) 

My goal is to do an updated release of the keystoneclient library, and then start using it from within the other openstack python client libraries to consolidate how authentication and authorization is done, at least to keep it all consistent.

I would very much appreciate feedback on the keystoneclient to get it to where it can be easily used from other clients. With the updates to keystoneclient, we also updated the method docstrings to hopefully make it much more clear how to use the client.

- joe

On Nov 11, 2012, at 2:35 PM, Steve Baker <sbaker at redhat.com> wrote:
> As Heat integrates with more OpenStack client libraries it has become obvious that there is a real lack of consistency in how client connections are created.
> 
> Our client connection handling can be seen here
> https://github.com/heat-api/heat/blob/master/heat/engine/clients.py
> 
> Horizon's connection handling is throughout these files
> https://github.com/openstack/horizon/tree/master/openstack_dashboard/api
> 
> The consistency issues include:
> - Keyword arguments differ for the same attributes
>   - username, user
>   - password, api-key
>   - project_id, tenant_id
>   - proxy_token, token, preauthtoken
> - Positional arguments vary from some to none
> - Some clients require an explicit call to authenticate()
> - When only a token is passed in, clients differ in what other parameters are required (if it works at all)
> 
> I think it should be possible to clean this up in a backwards-compatible way, and it seems that oslo (openstack-common) has a part to play here.
> 
> I'd like to suggest the following approach for feedback.
> 
> First to handle any differences in client behaviours (token handling, auth flows):
> - Document how clients should initialize and authenticate in both the username/password and token case. Maybe this exists already? Keystone developer help would be appreciated here.
> - Raise issues for clients who do things differently
> 
> In parallel, to make all client __init__ methods consistent:
> - Choose a client that does things the Right Way (python-keystoneclient?) that other clients should align with.
> - Write some code in oslo (openstack-common) which does the following
>   - consumes the positional and keyword arguments passed to client __init__
>   - log deprecation warnings for all positional arguments, and any non-blessed keywords
>   - validates arguments and raises ValueError
>   - transforms deprecated arguments to a standardised dict which the client uses for initialization
> - Port each client to use this, including a standard chunk to add to the docstring
> 
> Does this approach sound reasonable? I'd especially like to hear from any project that objects to their client lib getting this treatment.
> 
> cheers
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121111/c3627e14/attachment.html>