Open Stack

On Fri, Jan 17, 2014 at 11:03 PM, John Utz <John.Utz at 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.noller at 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" <rakhmerov at mirantis.com
> <mailto:rakhmerov at mirantis.com>> wrote:
>
> On 16 Jan 2014, at 13:06, Jesse Noller <jesse.noller at RACKSPACE.COM<mailto:
> jesse.noller at 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140118/c84458a0/attachment.html>