[openstack-dev] a "common" client library
Justin Hammond
justin.hammond at RACKSPACE.COM
Thu Jan 16 15:26:18 UTC 2014
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)?
On 1/15/14 10: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.
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>
>
>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
More information about the OpenStack-dev
mailing list