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