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" <[email protected]> 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 <[email protected]> > >Doug Hellmann <[email protected]> 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 >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > >_______________________________________________ >OpenStack-dev mailing list >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
