On Jan 16, 2014, at 9:26 AM, Justin Hammond <justin.hamm...@rackspace.com<mailto:justin.hamm...@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.kornie...@gmail.com<mailto:alexei.kornie...@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 <noo...@noorul.com<mailto:noo...@noorul.com>> Doug Hellmann <doug.hellm...@dreamhost.com<mailto:doug.hellm...@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev