Open Stack

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