<br><br><div class="gmail_quote">On Sun, Nov 11, 2012 at 10:18 PM, Steve Baker <span dir="ltr"><<a href="mailto:sbaker@redhat.com" target="_blank">sbaker@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 11/12/2012 01:00 PM, heckj wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Welcome to the client consolidation bandwagon :-)<br>
</blockquote></div>
I shall hitch my wagon and sharpen my yak shaving clippers.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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" target="_blank">https://launchpad.net/python-<u></u>openstackclient</a> for the launchpad project that we've been using to track and consolidate the progress on this kind of effort.<br>

</blockquote></div>
I'm aware of python-openstackclient, although it seems to be a unified CLI rather than a unified client library. python-openstackclient is like Heat and Horizon in that it consumes all the client libs and would benefit from them being consistent.<br>
</blockquote><div><br></div><div>We decided to start with the command line apps, but the Unified CLI project does have as a secondary goal improving the consistency of the client libraries, too.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Having said that, I look forward to integrating python-heatclient when momentum picks up again.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also immediately check out <a href="http://wiki.openstack.org/UnifiedCLI" target="_blank">http://wiki.openstack.org/<u></u>UnifiedCLI</a>, and <a href="http://wiki.openstack.org/UnifiedCLI/Authentication" target="_blank">http://wiki.openstack.org/<u></u>UnifiedCLI/Authentication</a> which document exactly what you're talking about.<br>

</blockquote></div>
This is still more CLI than library. The client CLIs probably do a better job of conforming to <a href="http://wiki.openstack.org/UnifiedCLI/Authentication" target="_blank">http://wiki.openstack.org/<u></u>UnifiedCLI/Authentication</a>, then they all do their own thing when initializing their connection object, then they all end up making the same correct keystone calls. Its the bit in the middle I'd like to fix.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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)<br>

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

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

</blockquote>
<br></div>
OK, I'll keep an eye on these changes as they land. It still looks like clients will be stuck with a backwards compatibility issue when moving to doing things the right way. Would not a deprecation shim still be useful in this case?</blockquote>
<div><br></div><div>A deprecation shim makes sense.</div><div><br></div><div>While we're on the topic of client library API changes, one of the main changes I would like to see is for the clients of projects like nova, cinder, glance, etc. to take a keystone client as argument instead of the user's credentials. That will allow, for example, the unified CLI to create a single keystone client instance and reuse it (and the token it provides) across the different services.</div>
<div><br></div><div>$0.02-ly,</div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
cheers<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br>