Open Stack

On Jan 16, 2014, at 9:26 AM, Justin Hammond <justin.hammond at RACKSPACE.COM<mailto:justin.hammond at RACKSPACE.COM>> wrote:

I'm not sure if it was said, but which httplib using being used (urllib3
maybe?). Also I noticed many people were talking about supporting auth
properly, but are there any intentions to properly support 'noauth'
(python-neutronclient, for instance, doesn't support it properly as of
this writing)?


Can you detail out noauth for me; and I would say the defacto httplib in python today is python-requests - urllib3 is also good but I would say from a *consumer* standpoint requests offers more in terms of usability / extensibility

On 1/15/14 10:53 PM, "Alexei Kornienko" <alexei.kornienko at gmail.com<mailto: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.

Do you need another person to make neutron client?


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<mailto:noorul at noorul.com>>

Doug Hellmann <doug.hellmann at dreamhost.com<mailto: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<mailto: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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto: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/76aac8cd/attachment.html>