On Jan 16, 2014, at 5:53 AM, Chmouel Boudjnah <chmo...@enovance.com<mailto:chmo...@enovance.com>> wrote:
On Thu, Jan 16, 2014 at 12:38 PM, Chris Jones <c...@tenshu.net<mailto:c...@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
