Open Stack

On Sat, 2014-01-18 at 09:13 -0500, Doug Hellmann wrote:
> 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

This *is* the approach Dean took with the CLI. Have a package that
provides the CLI but then have the actual work handed off to the
individual clients (with quite a lot of glue).

> 
> On Sat, Jan 18, 2014 at 1:00 AM, Jamie Lennox <jamielennox at 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-lists at cleverdevil.org>
>         > To: "OpenStack Development Mailing List (not for usage
>         questions)" <openstack-dev at 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 <
>         donald at stufft.io > wrote:
>         >
>         >
>         >
>         >
>         > On Jan 16, 2014, at 4:06 PM, Jesse Noller <
>         jesse.noller at RACKSPACE.COM >
>         > wrote:
>         >
>         >
>         >
>         >
>         >
>         > On Jan 16, 2014, at 2:22 PM, Renat Akhmerov <
>         rakhmerov at 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 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
>         
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev