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 <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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
