<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hey Steve,<div><br></div><div>Welcome to the client consolidation bandwagon :-)</div><div><br></div><div>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: <a href="https://launchpad.net/python-openstackclient">https://launchpad.net/python-openstackclient</a> for the launchpad project that we've been using to track and consolidate the progress on this kind of effort.</div><div><br></div><div>Also immediately check out <a href="http://wiki.openstack.org/UnifiedCLI">http://wiki.openstack.org/UnifiedCLI</a>, and <a href="http://wiki.openstack.org/UnifiedCLI/Authentication">http://wiki.openstack.org/UnifiedCLI/Authentication</a> which document exactly what you're talking about. </div><div><br></div><div>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) </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>- joe</div><div><br><div><div>On Nov 11, 2012, at 2:35 PM, Steve Baker <<a href="mailto:sbaker@redhat.com">sbaker@redhat.com</a>> wrote:</div><blockquote type="cite">
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<div bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
Our client connection handling can be seen here<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="https://github.com/heat-api/heat/blob/master/heat/engine/clients.py">https://github.com/heat-api/heat/blob/master/heat/engine/clients.py</a><br>
<br>
Horizon's connection handling is throughout these files<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="https://github.com/openstack/horizon/tree/master/openstack_dashboard/api">https://github.com/openstack/horizon/tree/master/openstack_dashboard/api</a><br>
<br>
The consistency issues include:<br>
- Keyword arguments differ for the same attributes<br>
- username, user<br>
- password, api-key<br>
- project_id, tenant_id<br>
- proxy_token, token, preauthtoken<br>
- Positional arguments vary from some to none<br>
- Some clients require an explicit call to authenticate()<br>
- When only a token is passed in, clients differ in what other
parameters are required (if it works at all)<br>
<br>
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.<br>
<br>
I'd like to suggest the following approach for feedback.<br>
<br>
First to handle any differences in client behaviours (token
handling, auth flows):<br>
- 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.<br>
- Raise issues for clients who do things differently<br>
<br>
In parallel, to make all client __init__ methods consistent:<br>
- Choose a client that does things the Right Way
(python-keystoneclient?) that other clients should align with.<br>
- Write some code in oslo (openstack-common) which does the
following<br>
- consumes the positional and keyword arguments passed to client
__init__<br>
- log deprecation warnings for all positional arguments, and any
non-blessed keywords<br>
- validates arguments and raises ValueError<br>
- transforms deprecated arguments to a standardised dict which the
client uses for initialization<br>
- Port each client to use this, including a standard chunk to add to
the docstring<br>
<br>
Does this approach sound reasonable? I'd especially like to hear
from any project that objects to their client lib getting this
treatment.<br>
<br>
cheers<br>
</div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></body></html>