Open Stack

*snip*
> 
> 
> Distinction between client layers won't get lost and would only be
> improved. My basic idea is the following:
> 
> 1) Transport layer would handle all transport related stuff - HTTP,
> JSON encoding, auth, caching, etc.
> 
> 2) Model layer (Resource classes, BaseManager, etc.) will handle data
> representation, validation
> 
> 3) API layer will handle all project specific stuff - url mapping,
> etc. (This will be imported to use client in other applications)
> 
> 4) Cli level will handle all stuff related to cli mapping - argparse,
> argcomplete, etc.
> 
> 
> >I believe the current effort referenced by the blueprint is focusing
> on moving existing code into the incubator for reuse, to make it
> easier to restructure later. Alexei, do I have that correct?
> 
> You are right. The first thing we do is try to make all clients
> look/work in similar way. After we'll continue our work with improving
> overall structure.

Wow, this thread took off. I'll jump in here as it's as good a point as
any. Sorry this will be long but i've been working on this for a while. 

So hopefully a few people know that we have been looking at addressing
this problem in keystoneclient as it really needs to be a/the base
client as it will handle authentication across all the projects.

I completely agree with your 4 sections, though i would really love to
see some more detail around levels 2 and 3. 

Section 1: Transport layer

For the majority i'm hoping that section 1 is in progress to being
solved. Keystoneclient introduced a session object which is designed to
handle HTTP communication for all the clients. This is a reusable object
and will contain an auth plugin such that all communication through the
session object will be authenticated. There is follow on work here to
have the session object manage the service catalog for clients so that a
client will simply specify the service type and version it needs to
communicate with. You can see the work around auth plugins and the
follow up here: https://review.openstack.org/#/c/60751/ (be aware that
backwards compatibility issues make it an ugly patch).

This solution was discussed at the HK summit and was generally accepted.
For an earlier draft of the vision around this see:
http://www.jamielennox.net/blog/2013/09/27/apiclient-communications/
which i should post a revision of. 

With this is mind a base client should look like not much more than:
https://review.openstack.org/#/c/60751/5/keystoneclient/baseclient.py


Section 4: CLI

Regarding section 4, my understanding is that all clients are moving
towards OSC for there CLI component. This is great. I personally like
the idea of the various python-*clients being controlled by their own
project as they are the people who best understand how to interact with
their services and design an API that makes sense to them.

I then would prefer that the CLI is controlled completely by OSC (not
plugins back to the client) because this way we end up with one
centralized choke point so that the CLI interface is common across all
the projects. Client developers will need to submit reviews to OSC to
add new CLI commands and connect it back to the client library. This
however is up to Dean and OSC, but i would prefer them to keep an eye on
this interface over the current system.


Section 2 & 3: Models and Managers

This is the part i've generally been concerned about. Firstly the idea
of having client code in OSLO seems stupid to me. Unlike the servers the
clients will often live in the same process as each other, particularly
with regards to exceptions this means that every client library now has
the same list of exceptions though in their own namespace so there is no
common way to handle an exception type when dealing with multiple
clients.

My concern with the common client code in OSLO is specifically that at
no time has there ever been a conversation about what a client should be
trying to achieve or the best way to do it. The code in apiclient is a
snapshot of what was in use across a number of projects at that time and
NOT any attempt to define a best practice. Whilst I understand the
desire to standardize, I and keystoneclient take backwards compatibility
very seriously and there is a lot of code in apiclient which does not
fit what I think a client should do and i do not want to support it
going forward.

Having said that I am very interested in figuring this out and defining
a common client framework. But it seems to me the sort of conversation
that we want to have at a summit session. Building this common framework
based on the current state of the clients is just formalizing the
current disaster.



To summarize, great! I'm the number one supported of improving and
unifying the clients. Please under there is existing work underway
towards this goal and that blindly copying oslo's apiclient everywhere
may be good for standardization but I don't think it really improves
anything and i'm not convinced it will make it easier to improve things
later.


Jamie



> 
> 2014/1/16 Noorul Islam K M <noorul at noorul.com>
>         Doug Hellmann <doug.hellmann at dreamhost.com> writes:
>         
>         > Several people have mentioned to me that they are interested
>         in, or
>         > actively working on, code related to a "common" client
>         library -- something
>         > meant to be reused directly as a basis for creating a common
>         library for
>         > all of the openstack clients to use. There's a blueprint [1]
>         in oslo, and I
>         > believe the keystone devs and unified CLI teams are probably
>         interested in
>         > ensuring that the resulting API ends up meeting all of our
>         various
>         > requirements.
>         >
>         > If you're interested in this effort, please subscribe to the
>         blueprint and
>         > use that to coordinate efforts so we don't produce more than
>         one common
>         > library. ;-)
>         >
>         
>         
>         Solum is already using it
>         https://review.openstack.org/#/c/58067/
>         
>         I would love to watch this space.
>         
>         Regards,
>         Noorul
>         
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>         
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev