On 01/16/2014 05:25 PM, Jesse Noller wrote:
On Jan 16, 2014, at 9:07 AM, Joe Gordon <joe.gord...@gmail.com
<mailto:joe.gord...@gmail.com>> wrote:
On Thu, Jan 16, 2014 at 9:45 AM, Jesse Noller
<jesse.nol...@rackspace.com <mailto:jesse.nol...@rackspace.com>> wrote:
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 <http://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
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.
Knowing usual openstack workflow I'm afraid that #1,#2 with a waterfall
approach may take years to be complete.
And after they'll be approved it will become clear that this
architecture is already outdated.
We try to use iterative approach for clients refactoring.
We started our work from removing code duplication because it already
gives a direct positive effect on client projects.
If you can show us better way of moving forward please help us by
uploading patches on this topic.
Talk is cheap. Show me the code. (c) Linus
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
