Open Stack

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

>
>  On Jan 16, 2014, at 9:07 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>
>
>
> 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.
>
>
>  Alexei and others have at least started the first stage of a rollout -
> the blueprint(s) needs additional work, planning and discussion, but his
> work is a good first step (reduce the duplication of code) although I am
> worried that the libraries and APIs / namespaces will need to change if we
> continue these discussions which potentially means re-doing work.
>
>  If we take a step back, a rollout process might be:
>
>  1: Solidify the libraries / layout / naming conventions (blueprint)
> 2: Solidify the APIs exposed to consumers (blueprint)
> 3: Pick up on the common-client-library-2 work which is primarily a
> migration of common code into oslo today, into the structure defined by 1 &
> 2
>
>  So, I sort of agree: moving / collapsing code now might be premature. I
> do strongly agree it should stand on its own as a library rather than an
> oslo incubator however. We should start with a single, clean namespace /
> library rather than depending on oslo directly.
>

Sounds good to me, thanks.


>
>  jesse
>
>
>
> _______________________________________________
> 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/ebdd5228/attachment.html>