On Thu, Jan 16, 2014 at 5:42 PM, Jesse Noller <[email protected]>wrote:
> > > On Jan 16, 2014, at 4:59 PM, "Renat Akhmerov" <[email protected]> > wrote: > > On 16 Jan 2014, at 13:06, Jesse Noller <[email protected]> > 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. > > > You may be right but not sure that adding another line into > requirements.txt is a huge loss of usability. > > > It is when that 1 dependency pulls in 6 others that pull in 10 more - > every little barrier or potential failure from the inability to make a > static binary to how each tool acts different is a paper cut of frustration > to an end user. > > Most of the time the clients don't even properly install because of > dependencies on setuptools plugins and other things. For developers (as > I've said) the story is worse: you have potentially 22+ individual packages > and their dependencies to deal with if they want to use a complete > openstack install from their code. > > So it doesn't boil down to just 1 dependency: it's a long laundry list > of things that make consumers' lives more difficult and painful. > > This doesn't even touch on the fact there aren't blessed SDKs or tools > pointing users to consume openstack in their preferred programming language. > > Shipping an API isn't enough - but it can be fixed easily enough. > +100 OpenStack must be attractive to our end users (developers and deployers), as I mentioned earlier. Let's make it as simple as "pip install openstack" if at all possible! -- Jonathan LaCour
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
