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
