On Fri, Jan 17, 2014 at 11:03 PM, John Utz <john....@wdc.com> wrote: > Outlook Web MUA, forgive the top post. :-( > > While a single import line that brings all the good stuff in at one shot > is very convenient for the creation of an application, it would muddy the > security picture *substantially* for the exact type of developer\customer > that you would be targeting with this sort of syntactic sugar. > > As Jesse alludes to below, the expanding tree of dependencies would be > masked by the aggregation. > > So, most likely, they would be pulling in vast numbers of things that they > don't require to get their simple app done (there's an idea! an eclipse > plugin that helpfully points out all the things that you are *not* using > and offers to redo your imports for you :-) ). >
I'm not sure what "vast numbers" of things you mean. The point is to make one thing to talk to an OpenStack cloud consistently, instead of a separate library for every facet of the cloud. Surely building on a common code base will have the opposite effect you suggest -- it should reduce the number of dependencies, and make it easier to track security updates in those dependencies. Doug > > As a result, when a security defect is published concerning one of those > hidden dependencies, they will not have any reason to think that it effects > them. > > just my us$0.02; > > johnu > ________________________________________ > From: Jesse Noller [jesse.nol...@rackspace.com] > Sent: Thursday, January 16, 2014 5:42 PM > To: OpenStack Development Mailing List (not for usage questions) > Cc: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] a "common" client library > > On Jan 16, 2014, at 4:59 PM, "Renat Akhmerov" <rakhme...@mirantis.com > <mailto:rakhme...@mirantis.com>> wrote: > > On 16 Jan 2014, at 13:06, Jesse Noller <jesse.nol...@rackspace.com<mailto: > 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. > > Renat Akhmerov > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org<mailto: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