I like the idea of a fresh start, but I don't think that's incompatible
with the other work to clean up the existing clients. That cleanup work
could help with creating the backwards compatibility layer, if a new
library needs to include one, for example.

As far as namespace packages and separate client libraries, I'm torn. It
makes sense, and I originally assumed we would want to take that approach.
The more I think about it, though, the more I like the approach Dean took
with the CLI, creating a single repository with a team responsible for
managing consistency in the UI.

Doug


On Sat, Jan 18, 2014 at 1:00 AM, Jamie Lennox <jamielen...@redhat.com>wrote:

> I can't see any reason that all of these situations can't be met.
>
> We can finally take the openstack pypi namespace, move keystoneclient ->
> openstack.keystone and similar for the other projects. Have them all based
> upon openstack.base and probably an openstack.transport for transport.
>
> For the all-in-one users we can then just have openstack.client which
> depends on all of the openstack.x projects. This would satisfy the
> requirement of keeping projects seperate, but having the one entry point
> for newer users. Similar to the OSC project (which could acutally rely on
> the new all-in-one).
>
> This would also satisfy a lot of the clients who have i know are looking
> to move to a version 2 and break compatability with some of the crap from
> the early days.
>
> I think what is most important here is deciding what we want from our
> clients and discussing a common base that we are happy to support - not
> just renaming the existing ones.
>
> (I don't buy the problem with large amounts of dependencies, if you have a
> meta-package you just have one line in requirements and pip will figure the
> rest out.)
>
> Jamie
>
> ----- Original Message -----
> > From: "Jonathan LaCour" <jonathan-li...@cleverdevil.org>
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> > Sent: Saturday, 18 January, 2014 4:00:58 AM
> > Subject: Re: [openstack-dev] a "common" client library
> >
> > On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft < don...@stufft.io >
> wrote:
> >
> >
> >
> >
> > On Jan 16, 2014, at 4:06 PM, Jesse Noller < jesse.nol...@rackspace.com >
> > wrote:
> >
> >
> >
> >
> >
> > On Jan 16, 2014, at 2:22 PM, Renat Akhmerov < rakhme...@mirantis.com >
> wrote:
> >
> >
> >
> >
> > Since it’s pretty easy to get lost among all the opinions I’d like to
> > clarify/ask a couple of things:
> >
> >
> >
> >     * Keeping all the clients physically separate/combining them in to a
> >     single library. Two things here:
> >         * In case of combining them, what exact project are we
> considering?
> >         If this list is limited to core projects like nova and keystone
> what
> >         policy could we have for other projects to join this list?
> >         (Incubation, graduation, something else?)
> >         * In terms of granularity and easiness of development I’m for
> keeping
> >         them separate but have them use the same boilerplate code,
> basically
> >         we need a OpenStack Rest Client Framework which is flexible
> enough
> >         to address all the needs in an abstract domain agnostic manner. I
> >         would assume that combining them would be an additional
> >         organizational burden that every stakeholder would have to deal
> >         with.
> >
> > Keeping them separate is awesome for *us* but really, really, really
> sucks
> > for users trying to use the system.
> >
> > I agree. Keeping them separate trades user usability for developer
> usability,
> > I think user usability is a better thing to strive for.
> > 100% agree with this. In order for OpenStack to be its most successful, I
> > believe firmly that a focus on end-users and deployers needs to take the
> > forefront. That means making OpenStack clouds as easy to
> consume/leverage as
> > possible for users and tool builders, and simplifying/streamlining as
> much
> > as possible.
> >
> > I think that a single, common client project, based upon package
> namespaces,
> > with a unified, cohesive feel is a big step in this direction.
> >
> > --
> > Jonathan LaCour
> >
> >
> > _______________________________________________
> > 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
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to