<div dir="ltr"><div class="gmail_default" style="font-size:small">I like the idea of a fresh start, but I don't think that's incompatible with the other work to clean up the existing clients. That cleanup work could help with creating the backwards compatibility layer, if a new library needs to include one, for example.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As far as namespace packages and separate client libraries, I'm torn. It makes sense, and I originally assumed we would want to take that approach. The more I think about it, though, the more I like the approach Dean took with the CLI, creating a single repository with a team responsible for managing consistency in the UI.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Doug</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jan 18, 2014 at 1:00 AM, Jamie Lennox <span dir="ltr"><<a href="mailto:jamielennox@redhat.com" target="_blank">jamielennox@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can't see any reason that all of these situations can't be met.<br>
<br>
We can finally take the openstack pypi namespace, move keystoneclient -> openstack.keystone and similar for the other projects. Have them all based upon openstack.base and probably an openstack.transport for transport.<br>
<br>
For the all-in-one users we can then just have openstack.client which depends on all of the openstack.x projects. This would satisfy the requirement of keeping projects seperate, but having the one entry point for newer users. Similar to the OSC project (which could acutally rely on the new all-in-one).<br>
<br>
This would also satisfy a lot of the clients who have i know are looking to move to a version 2 and break compatability with some of the crap from the early days.<br>
<br>
I think what is most important here is deciding what we want from our clients and discussing a common base that we are happy to support - not just renaming the existing ones.<br>
<br>
(I don't buy the problem with large amounts of dependencies, if you have a meta-package you just have one line in requirements and pip will figure the rest out.)<br>
<br>
Jamie<br>
<div class="im"><br>
----- Original Message -----<br>
> From: "Jonathan LaCour" <<a href="mailto:jonathan-lists@cleverdevil.org">jonathan-lists@cleverdevil.org</a>><br>
> To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Sent: Saturday, 18 January, 2014 4:00:58 AM<br>
> Subject: Re: [openstack-dev] a "common" client library<br>
><br>
</div><div class="im">> On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft < <a href="mailto:donald@stufft.io">donald@stufft.io</a> > wrote:<br>
><br>
><br>
><br>
><br>
> On Jan 16, 2014, at 4:06 PM, Jesse Noller < <a href="mailto:jesse.noller@RACKSPACE.COM">jesse.noller@RACKSPACE.COM</a> ><br>
> wrote:<br>
><br>
><br>
><br>
><br>
><br>
> On Jan 16, 2014, at 2:22 PM, Renat Akhmerov < <a href="mailto:rakhmerov@mirantis.com">rakhmerov@mirantis.com</a> > wrote:<br>
><br>
><br>
><br>
><br>
> Since it’s pretty easy to get lost among all the opinions I’d like to<br>
> clarify/ask a couple of things:<br>
><br>
><br>
><br>
</div>> * Keeping all the clients physically separate/combining them in to a<br>
<div class="im">> single library. Two things here:<br>
</div>> * In case of combining them, what exact project are we considering?<br>
<div class="im">> If this list is limited to core projects like nova and keystone what<br>
> policy could we have for other projects to join this list?<br>
> (Incubation, graduation, something else?)<br>
</div>> * In terms of granularity and easiness of development I’m for keeping<br>
<div class="im HOEnZb">> them separate but have them use the same boilerplate code, basically<br>
> we need a OpenStack Rest Client Framework which is flexible enough<br>
> to address all the needs in an abstract domain agnostic manner. I<br>
> would assume that combining them would be an additional<br>
> organizational burden that every stakeholder would have to deal<br>
> with.<br>
><br>
> Keeping them separate is awesome for *us* but really, really, really sucks<br>
> for users trying to use the system.<br>
><br>
> I agree. Keeping them separate trades user usability for developer usability,<br>
> I think user usability is a better thing to strive for.<br>
> 100% agree with this. In order for OpenStack to be its most successful, I<br>
> believe firmly that a focus on end-users and deployers needs to take the<br>
> forefront. That means making OpenStack clouds as easy to consume/leverage as<br>
> possible for users and tool builders, and simplifying/streamlining as much<br>
> as possible.<br>
><br>
> I think that a single, common client project, based upon package namespaces,<br>
> with a unified, cohesive feel is a big step in this direction.<br>
><br>
> --<br>
> Jonathan LaCour<br>
><br>
><br>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
<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>
</div></div></blockquote></div><br></div></div>