On Thu, Jan 16, 2014 at 10:25 AM, Jesse Noller <jesse.nol...@rackspace.com>wrote:
> > On Jan 16, 2014, at 9:07 AM, Joe Gordon <joe.gord...@gmail.com> wrote: > > > > > On Thu, Jan 16, 2014 at 9:45 AM, Jesse Noller > <jesse.nol...@rackspace.com>wrote: > >> >> On Jan 16, 2014, at 5:53 AM, Chmouel Boudjnah <chmo...@enovance.com> >> wrote: >> >> >> On Thu, Jan 16, 2014 at 12:38 PM, Chris Jones <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.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@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
