Open Stack

On Jan 16, 2014, at 5:53 AM, Chmouel Boudjnah <chmouel at enovance.com<mailto:chmouel at enovance.com>> wrote:


On Thu, Jan 16, 2014 at 12:38 PM, Chris Jones <cmsj at tenshu.net<mailto:cmsj at tenshu.net>> wrote:
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)?


that's what openstackclient is here for https://github.com/openstack/python-openstackclient

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.

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.

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:

from openstack.common.api import Auth
from openstack.common.api import Compute
from openstack.common.util import cli_tools

my_cli = cli_tools.build(…)

def my_command(cli):
compute = Compute(Auth(cli.tentant…, connect=True))
compute.list_flavors()

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.

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.

Some of the additions that came out of this email threads and others:

1. Common backend should provide / offer caching utilities
2. Auth retries need to be handled by the auth object, and each sub-project delegates to the auth object to manage that.
3. Verified Mocks / Stubs / Fakes must be provided for proper unit testing

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140116/c97090a5/attachment.html>