Open Stack

On Sun, Nov 11, 2012 at 10:18 PM, Steve Baker <sbaker at redhat.com> wrote:

> On 11/12/2012 01:00 PM, heckj wrote:
>
>> Welcome to the client consolidation bandwagon :-)
>>
> I shall hitch my wagon and sharpen my yak shaving clippers.
>
>
>  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<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.
>>
> 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.
>

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.


>
> Having said that, I look forward to integrating python-heatclient when
> momentum picks up again.
>
>
>  Also immediately check out http://wiki.openstack.org/**UnifiedCLI<http://wiki.openstack.org/UnifiedCLI>,
>> and http://wiki.openstack.org/**UnifiedCLI/Authentication<http://wiki.openstack.org/UnifiedCLI/Authentication>which document exactly what you're talking about.
>>
> This is still more CLI than library. The client CLIs probably do a better
> job of conforming to http://wiki.openstack.org/**UnifiedCLI/Authentication<http://wiki.openstack.org/UnifiedCLI/Authentication>,
> 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.
>
>
>  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.
>>
>
> 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?


A deprecation shim makes sense.

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.

$0.02-ly,
Doug


>
>
> cheers
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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/20121113/c29cd7b7/attachment.html>