Open Stack

On Wed, Jan 15, 2014 at 7:53 PM, Alexei Kornienko <
alexei.kornienko at gmail.com> wrote:

> >I did notice, however, that neutronclient is
> conspicuously absent from the Work Items in the blueprint's Whiteboard.
> It will surely be added later. We already working on several things in
> parallel and we will add neutronclient soon.
>
>
> >I would love to see a bit more detail on the structure of the lib(s), the
> blueprint really doesn't discuss the design/organization/intended API of
> the libs.  For example, I would hope the distinction between the various
> layers of a client stack don't get lost, i.e. not mixing the low-level REST
> API bits with the higher-level CLI parsers and decorators.
> >Does the long-term goals include a common caching layer?
>
> 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'm really excited about this. I think consolidating layers 1 and 4 will be
a huge benefit for deployers and users.

I'm hoping we can structure layers 2 and 3 a bit flexibly to allow for
existing project differences and proper ownership. For example, in Glance
we use jsonschema somewhat so our validation is a bit different. Also, I
consider the definition of resources and url mappings for images to be
something that should be owned by the Images program. I'm confident,
however, that we can figure out how to structure the libraries,
deliverables, and process to reflect that ownership.


>
> >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.
>
>
>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140116/29c15db1/attachment.html>