<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<br>
<div>
<div>On Jan 16, 2014, at 9:26 AM, Justin Hammond <<a href="mailto:justin.hammond@RACKSPACE.COM">justin.hammond@RACKSPACE.COM</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
I'm not sure if it was said, but which httplib using being used (urllib3<br>
maybe?). Also I noticed many people were talking about supporting auth<br>
properly, but are there any intentions to properly support 'noauth'<br>
(python-neutronclient, for instance, doesn't support it properly as of<br>
this writing)?<span class="Apple-converted-space"> </span><br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>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 </div>
<br>
<blockquote type="cite">
<div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
On 1/15/14 10:53 PM, "Alexei Kornienko" <<a href="mailto:alexei.kornienko@gmail.com">alexei.kornienko@gmail.com</a>> wrote:<br>
<br>
<blockquote type="cite">
<blockquote type="cite">I did notice, however, that neutronclient is<br>
</blockquote>
conspicuously absent from the Work Items in the blueprint's Whiteboard.<br>
<br>
It will surely be added later. We already working on several things in<br>
parallel and we will add neutronclient soon.<br>
</blockquote>
<br>
Do you need another person to make neutron client?<br>
<br>
<blockquote type="cite"><br>
<blockquote type="cite">I would love to see a bit more detail on the structure of the<br>
</blockquote>
lib(s), the blueprint really doesn't discuss the<br>
design/organization/intended API of the libs. For example, I would hope<br>
the distinction between the various layers of a client stack don't get<br>
lost, i.e. not mixing the low-level REST API bits with the higher-level<br>
CLI parsers and decorators.<br>
<blockquote type="cite">Does the long-term goals include a common caching layer?<br>
</blockquote>
<br>
<br>
Distinction between client layers won't get lost and would only be<br>
improved. My basic idea is the following:<br>
<br>
1) Transport layer would handle all transport related stuff - HTTP, JSON<br>
encoding, auth, caching, etc.<br>
<br>
2) Model layer (Resource classes, BaseManager, etc.) will handle data<br>
representation, validation<br>
<br>
3) API layer will handle all project specific stuff - url mapping, etc.<br>
(This will be imported to use client in other applications)<br>
<br>
4) Cli level will handle all stuff related to cli mapping - argparse,<br>
argcomplete, etc.<br>
<br>
<br>
<blockquote type="cite">I believe the current effort referenced by the blueprint is focusing on<br>
</blockquote>
moving existing code into the incubator for reuse, to make it easier to<br>
restructure later. Alexei, do I have that correct?<br>
<br>
You are right. The first thing we do is try to make all clients look/work<br>
in similar way. After we'll continue our work with improving overall<br>
structure.<br>
<br>
<br>
<br>
<br>
<br>
<br>
2014/1/16 Noorul Islam K M <<a href="mailto:noorul@noorul.com">noorul@noorul.com</a>><br>
<br>
Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>> writes:<br>
<br>
<blockquote type="cite">Several people have mentioned to me that they are interested in, or<br>
actively working on, code related to a "common" client library --<br>
something<br>
meant to be reused directly as a basis for creating a common library for<br>
all of the openstack clients to use. There's a blueprint [1] in oslo,<br>
and I<br>
believe the keystone devs and unified CLI teams are probably interested<br>
in<br>
ensuring that the resulting API ends up meeting all of our various<br>
requirements.<br>
<br>
If you're interested in this effort, please subscribe to the blueprint<br>
and<br>
use that to coordinate efforts so we don't produce more than one common<br>
library. ;-)<br>
<br>
</blockquote>
<br>
<br>
Solum is already using it <a href="https://review.openstack.org/#/c/58067/">https://review.openstack.org/#/c/58067/</a><br>
<br>
I would love to watch this space.<br>
<br>
Regards,<br>
Noorul<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div>
</blockquote>
</div>
<br>
</body>
</html>