<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 16, 2014 at 12:03 AM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 15/01/14 21:35 +0000, Jesse Noller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Jan 15, 2014, at 1:37 PM, Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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. ;-)<br>
<br>
Thanks,<br>
Doug<br>
<br>
<br>
[1] <a href="https://blueprints.launchpad.net/oslo/+spec/common-client-library-2" target="_blank">https://blueprints.launchpad.<u></u>net/oslo/+spec/common-client-<u></u>library-2</a><br>
</blockquote>
<br>
*raises hand*<br>
<br>
Me me!<br>
<br>
I’ve been talking to many contributors about the Developer Experience stuff I emailed out prior to the holidays and I was starting blueprint work, but this is a great pointer. I’m going to have to sync up with Alexei.<br>
<br>
I think solving this for openstack developers and maintainers as the blueprint says is a big win in terms of code reuse / maintenance and consistent but more so for *end-user developers* consuming openstack clouds.<br>
<br>
Some background - there’s some terminology mismatch but the rough idea is the same:<br>
<br>
* A centralized “SDK” (Software Development Kit) would be built condensing the common code and logic and operations into a single namespace.<br>
<br>
* This SDK would be able to be used by “downstream” CLIs - essentially the CLIs become a specialized front end - and in some cases, only an argparse or cliff front-end to the SDK methods located in the (for example) openstack.client.api.compute<br>
<br>
* The SDK would handle Auth, re-auth (expired tokens, etc) for long-lived clients - all of the openstack.client.api.** classes would accept an Auth object to delegate management / mocking of the Auth / service catalog stuff to. This means developers building applications (say for example, horizon) don’t need to worry about token/expired authentication/etc.<br>
<br>
* Simplify the dependency graph & code for the existing tools to enable single binary installs (py2exe, py2app, etc) for end users of the command line tools.<br>
<br>
Short version: if a developer wants to consume an openstack cloud; the would have a single SDK with minimal dependencies and import from a single namespace. An example application might look like:<br>
<br>
from openstack.api import AuthV2<br>
from openstack.api import ComputeV2<br>
<br>
myauth = AuthV2(…., connect=True)<br>
compute = ComputeV2(myauth)<br>
<br>
compute.list_flavors()<br>
<br>
</blockquote>
<br></div>
I know this is an example but, could we leave the version out of the<br>
class name? Having something like:<br>
<br>
from openstack.api.v2 import Compute<br>
<br>
or<br>
<br>
from openstack.compute.v2 import Instance<br>
<br>
(just made that up)<br>
<br>
for marconi we're using the later.</blockquote><div><br></div><div>Just throwing this out there because it seems relevant to client design.</div><div><br></div><div>As we've been looking at porting clients to using v2 of the Images API, its seems more and more to me that including the *server* version in the main import path is a real obstacle.</div>
<div><br></div><div>IMO any future client libs should write library interfaces based on the peculiarities of user needs, not based on the vagaries of the server version. So as a user of this library I would do something like:</div>
<div><br></div><div> 1 from openstack.api import images</div><div> 2 client = images.make_me_a_client(auth_url, etcetera) # all version negotiation is happening here</div><div> 3 client.list_images() # works more or less same no matter who I'm talking to</div>
<div><br></div><div>Now, there would still likely be hidden implementation code that is different per server version and which is instantiated in line 2 above, and maybe that's the library path stuff you are talking about.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This greatly improves the developer experience both internal to openstack and externally. Currently OpenStack has 22+ (counting stackforge) potential libraries a developer may need to install to use a full deployment of OpenStack:<br>
<br>
* python-keystoneclient (identity)<br>
* python-glanceclient (image)<br>
* python-novaclient (compute)<br>
* python-troveclient (database)<br>
* python-neutronclient (network)<br>
* python-ironicclient (bare metal)<br>
* python-heatclient (orchestration)<br>
* python-cinderclient (block storage)<br>
* python-ceilometerclient (telemetry, metrics & billing)<br>
* python-swiftclient (object storage)<br>
* python-savannaclient (big data)<br>
* python-openstackclient (meta client package)<br>
* python-marconiclient (queueing)<br>
* python-tuskarclient (tripleo / management)<br>
* python-melangeclient (dead)<br>
* python-barbicanclient (secrets)<br>
* python-solumclient (ALM)<br>
* python-muranoclient (application catalog)<br>
* python-manilaclient (shared filesystems)<br>
* python-libraclient (load balancers)<br>
* python-climateclient (reservations)<br>
* python-designateclient (Moniker/DNS)<br>
<br>
If you exclude the above and look on PyPI:<br>
<br>
On PyPi (client libraries/SDKs only, excluding the above - not maintained by openstack):<br>
<br>
* hpcloud-auth-openstack 1.0<br>
* python-openstackclient 0.2.2<br>
* rackspace-auth-openstack 1.1<br>
* posthaste 0.2.2<br>
* pyrax 1.6.2<br>
* serverherald 0.0.1<br>
* warm 0.3.1<br>
* vaporize 0.3.2<br>
* swiftsc (<a href="https://github.com/mkouhei/swiftsc" target="_blank">https://github.com/mkouhei/<u></u>swiftsc</a>)<br>
* bookofnova 0.007<br>
* nova-adminclient 0.1.8<br>
* python-quantumclient 2.2.4.3<br>
* python-stackhelper 0.0.7.1.gcab1eb0<br>
* swift-bench 1.0<br>
* swiftly 1.12<br>
* txAWS 0.2.3<br>
* cfupload 0.5.1<br>
* python-reddwarfclient 0.1.2<br>
* python-automationclient 1.2.1<br>
* rackspace-glanceclient 0.9<br>
* rackspace-novaclient 1.4<br>
<br>
If you ignore PyPI and just want to install the base say - 7 services, each one of the python-** clients has its own dependency tree and may or may not build from one of the others. If a vendor wants to extend any of them, it’s basically a fork instead of a clean plugin system.<br>
<br>
On the CLI front - this would *greatly* simplify the work openstackclient needs to do - it would be able to import from the main SDK and simply provide the noun-verb command line and any other end-user sugar it wanted to. Even if each service wanted to keep its own python-X client instead of relying on openstackclient it would be minimal to depend on the core SDK and then plugin/extend to build a specialized CLI for the project - if you really wanted, you could also extend openstackclient directly.<br>
</blockquote>
<br></div></div>
Thanks for the info. It's a great way to see where we're standing now<br>
and the relevance of this argument.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Roughly this is the punch list I was looking at:<br>
<br>
1: a blueprint that explains the rationale behind unifying the Client code from the openstack clients; using a single REST interface, common object hierarchy, etc.<br>
2: A path for implementation of the common SDK including operational code<br>
<br>
4: dealing with a single binary cross platform for the CLI that derives from the common SDK (hard requirement)<br>
5: Standardization of names (e.g Compute != Nova, use the real names, not project names)<br>
6: Allow vendors to alias names for services to match their offerings<br>
</blockquote>
<br></div>
+1<br>
<br>
Keeping the library separated from the CLI binary is a most. Marconi<br>
client, for instance, is just a library and we are planning to use<br>
openstack's common client for the CLI.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I’ll begin working on the blueprint you pointed to - given this is more akin to a horizon-like UX project than a sub project of Oslo itself; does it really belong there? I do see the work within the individual clients:<br>
<br>
<a href="https://review.openstack.org/#/q/topic:bp/common-client-library-2,n,z" target="_blank">https://review.openstack.org/#<u></u>/q/topic:bp/common-client-<u></u>library-2,n,z</a><br>
<br>
Jamie’s comments in:<br>
<br>
<a href="https://review.openstack.org/#/c/63164/" target="_blank">https://review.openstack.org/#<u></u>/c/63164/</a><br>
<br>
Do concern me as I’d like to not do this as a lowest common denominator; in this case the client code for keystoneclient might be in openstack.api.auth but it would be able to be as advanced as it would like from an api standpoint - and whatever subset of functionality could be exposed in higher level abstractions (such as a CLI). Bonus is that horizon could potentially use this work.<br>
</blockquote>
<br></div>
This one last point is very important as well. The levels of<br>
abstraction of the common SDK and CLI shouldn't prevent services from<br>
specializing it.<br>
<br>
FF<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
@flaper87<br>
Flavio Percoco<br>
</font></span><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>