<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 15, 2014 at 7:53 PM, Alexei Kornienko <span dir="ltr"><<a href="mailto:alexei.kornienko@gmail.com" target="_blank">alexei.kornienko@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="im"><div>>I did notice, however, that neutronclient is<br>
conspicuously absent from the Work Items in the blueprint's Whiteboard.<br></div></div>It will surely be added later. We already working on several things in parallel and we will add neutronclient soon.<div class="im">
<br><br>>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.
<div></div><div>>Does the long-term goals include a common caching layer?<br><br></div></div><div>Distinction between client layers won't get lost and would only be improved. My basic idea is the following:<br></div>
<div>
1) Transport layer would handle all transport related stuff - HTTP, JSON encoding, auth, caching, etc.<br></div><div>2) Model layer (Resource classes, BaseManager, etc.) will handle data representation, validation<br></div>

<div>3) API layer will handle all project specific stuff - url mapping, etc. (This will be imported to use client in other applications)<br></div><div>4) Cli level will handle all stuff related to cli mapping - argparse, argcomplete, etc.<br>
</div></div></div></blockquote><div><br></div><div>I'm really excited about this. I think consolidating layers 1 and 4 will be a huge benefit for deployers and users.</div><div><br></div><div>I'm hoping we can structure layers 2 and 3 a bit flexibly to allow for existing project differences and proper ownership. For example, in Glance we use jsonschema somewhat so our validation is a bit different. Also, I consider the definition of resources and url mappings for images to be something that should be owned by the Images program. I'm confident, however, that we can figure out how to structure the libraries, deliverables, and process to reflect that ownership.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>
</div><div class="im"><br>>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. <span style="font-family:arial,sans-serif">Alexei, do I have that correct?<br></span></div></div><span style="font-family:arial,sans-serif">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.<br>

</span><div><br><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/16 Noorul Islam K M <span dir="ltr"><<a href="mailto:noorul@noorul.com" target="_blank">noorul@noorul.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>> writes:<br>


<br>
> Several people have mentioned to me that they are interested in, or<br>
> actively working on, code related to a "common" client library -- 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, and I<br>
> believe the keystone devs and unified CLI teams are probably interested 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 and<br>
> use that to coordinate efforts so we don't produce more than one common<br>
> library. ;-)<br>
><br>
<br>
</div>Solum is already using it <a href="https://review.openstack.org/#/c/58067/" target="_blank">https://review.openstack.org/#/c/58067/</a><br>
<br>
I would love to watch this space.<br>
<br>
Regards,<br>
Noorul<br>
<div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><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" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>