<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 16, 2014, at 5:53 AM, Chmouel Boudjnah <<a href="mailto:chmouel@enovance.com">chmouel@enovance.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Jan 16, 2014 at 12:38 PM, Chris Jones <span dir="ltr">
<<a href="mailto:cmsj@tenshu.net" target="_blank">cmsj@tenshu.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Once a common library is in place, is there any intention to (or resistance against) collapsing the clients into a single project or even a single command (a la busybox)?</blockquote>
</div>
<br>
<br>
</div>
<div class="gmail_extra">that's what openstackclient is here for <a href="https://github.com/openstack/python-openstackclient">
https://github.com/openstack/python-openstackclient</a><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>After speaking with people working on OSC and looking at the code base in depth; I don’t think this addresses what Chris is implying: OSC wraps the individual CLIs built by each project today, instead of the inverse: a common backend that the individual
CLIs can wrap - the latter is an important distinction as currently, building a single binary install of OSC for say, Windows is difficult given the dependency tree incurred by each of the wrapped CLIs, difference in dependencies, structure, etc.</div>
<div><br>
</div>
<div>Also, wrapping a series of inconsistent back end Client classes / functions / methods means that the layer that presents a consistent user interface (OSC) to the user is made more complex juggling names/renames/commands/etc. </div>
<div><br>
</div>
<div>In the inverted case of what we have today (single backend); as a developer of user interfaces (CLIs, Applications, Web apps (horizon)) you would be able to:</div>
<div><br>
</div>
<div>
<div>from openstack.common.api import Auth</div>
</div>
<div>from openstack.common.api import Compute</div>
<div>from openstack.common.util import cli_tools</div>
<div><br>
</div>
<div>my_cli = cli_tools.build(…)</div>
<div><br>
</div>
<div>def my_command(cli):</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>compute = Compute(Auth(cli.tentant…, connect=True))</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>compute.list_flavors()</div>
<div><br>
</div>
<div>This would mean that *even if the individual clients needed or wanted to keep their specific CLIs, they would be able to use a not “least common denominator” back end (each service can have a rich common.api.compute.py or api.compute/client.py and extend
where needed. However tools like horizon / openstackclient can choose not to leverage the “power user/operator/admin” components and present a simplified user interface.</div>
<div><br>
</div>
<div>I’m working on a wiki page + blueprint to brainstorm how we could accomplish this based off of what work is in flight today (see doug’s linked blueprint) and sussing out a layout / API strawman for discussion. </div>
<div><br>
</div>
<div>Some of the additions that came out of this email threads and others:</div>
<div><br>
</div>
<div>1. Common backend should provide / offer caching utilities </div>
<div>2. Auth retries need to be handled by the auth object, and each sub-project delegates to the auth object to manage that.</div>
<div>3. Verified Mocks / Stubs / Fakes must be provided for proper unit testing </div>
<div><span class="Apple-tab-span" style="white-space:pre"></span></div>
<div><span class="Apple-tab-span" style="white-space:pre"></span></div>
<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>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
</div>
<br>
</body>
</html>