<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 17, 2014 at 11:03 PM, John Utz <span dir="ltr"><<a href="mailto:John.Utz@wdc.com" target="_blank">John.Utz@wdc.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Outlook Web MUA, forgive the top post. :-(<br>
<br>
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.<br>
<br>
As Jesse alludes to below, the expanding tree of dependencies would be masked by the aggregation.<br>
<br>
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 :-) ).<br>
</blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
just my us$0.02;<br>
<br>
johnu<br>
________________________________________<br>
From: Jesse Noller [<a href="mailto:jesse.noller@RACKSPACE.COM">jesse.noller@RACKSPACE.COM</a>]<br>
Sent: Thursday, January 16, 2014 5:42 PM<br>
<div class="im">To: OpenStack Development Mailing List (not for usage questions)<br>
</div>Cc: OpenStack Development Mailing List (not for usage questions)<br>
<div class="im">Subject: Re: [openstack-dev] a "common" client library<br>
<br>
</div>On Jan 16, 2014, at 4:59 PM, "Renat Akhmerov" <<a href="mailto:rakhmerov@mirantis.com">rakhmerov@mirantis.com</a><mailto:<a href="mailto:rakhmerov@mirantis.com">rakhmerov@mirantis.com</a>>> wrote:<br>
<div class="im"><br>
On 16 Jan 2014, at 13:06, Jesse Noller <<a href="mailto:jesse.noller@RACKSPACE.COM">jesse.noller@RACKSPACE.COM</a><mailto:<a href="mailto:jesse.noller@RACKSPACE.COM">jesse.noller@RACKSPACE.COM</a>>> wrote:<br>
<br>
Since it’s pretty easy to get lost among all the opinions I’d like to clarify/ask a couple of things:<br>
<br>
<br>
</div> * Keeping all the clients physically separate/combining them in to a single library. Two things here:<br>
* 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?)<br>
* 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.<br>
<div class="im"><br>
Keeping them separate is awesome for *us* but really, really, really sucks for users trying to use the system.<br>
<br>
You may be right but not sure that adding another line into requirements.txt is a huge loss of usability.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Shipping an API isn't enough - but it can be fixed easily enough.<br>
<br>
Renat Akhmerov<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
</div><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>