On Jan 16, 2014, at 8:42 PM, Jesse Noller <jesse.nol...@rackspace.com> wrote:
> > > On Jan 16, 2014, at 4:59 PM, "Renat Akhmerov" <rakhme...@mirantis.com> wrote: > >> On 16 Jan 2014, at 13:06, Jesse Noller <jesse.nol...@rackspace.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. >> >> 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. There’s also the discovery problem, it’s incredibly frustrating if, as I’m starting out to use an Openstack based cloud, everytime I want to touch some new segment of the service I need to go find out what the client lib is for that, possibly download the dependencies for it, possibly get it approved, etc. Splitting up services makes a lot of sense on the server side, but to the consumer a cloud often times isn’t a disjoint set of services that happen to be working in parallel, it is a single unified product where they may not know the boundary lines, or at the very least the boundaries can be fuzzy for them. > >> Renat Akhmerov >> _______________________________________________ >> 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 ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
