Open Stack

On Thu, Jan 16, 2014 at 9:45 AM, Jesse Noller <jesse.noller at rackspace.com>wrote:

>
>  On Jan 16, 2014, at 5:53 AM, Chmouel Boudjnah <chmouel at enovance.com>
> wrote:
>
>
> On Thu, Jan 16, 2014 at 12:38 PM, Chris Jones <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.pyor 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
>

I am happy to see this work being done, there is definitely a lot of work
to be done on the clients.

This blueprint sounds like its still being fleshed out, so I am wondering
what the value is of the current patches
https://review.openstack.org/#/q/topic:bp/common-client-library-2,n,z

Those patches mainly sync cliutils and apiutils from oslo into the assorted
clients. But if this blueprint is about the python API and not the CLI (as
that would be the openstack-pythonclient), why sync in apiutils?

Also does this need to go through oslo-incubator or can this start out as a
library? Making this a library earlier on will reduce the number of patches
needed to get 20+ repositories to use this.




>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/306b826d/attachment.html>