[openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

Doug Hellmann doug at doughellmann.com
Mon Apr 18 18:30:35 UTC 2016


Excerpts from Sean Dague's message of 2016-04-18 13:49:31 -0400:
> On 04/18/2016 01:33 PM, Doug Hellmann wrote:
> > Excerpts from Matthew Thode's message of 2016-04-18 10:23:37 -0500:
> <snip>
> >> To add to this, I'd also note that I as a packager would likely stop
> >> packaging Openstack at whatever release this goes into.  While the
> >> option to package and ship a virtualenv installed to /usr/local or /opt
> >> exists bundling is not something that should be supported given the
> >> issues it can have (update cadence and security issues mainly).
> > 
> > That's a useful data point, but it comes across as a threat and I'm
> > having trouble taking it as a constructive comment.
> > 
> > Can you truly not imagine any other useful way to package OpenStack
> > other than individual packages with shared dependencies that would
> > be acceptable?
> 
> I think it's important to realize that if we go down this route, I'd
> expect a lot of community  distros to take that stand point. Only
> distros with a product will be able to take on the work.
> 
> We often get annoyed with projects in our own space being "special
> snowflakes" and doing things differently. OpenStack demanding that every
> component has a copy of it's own dependencies is definitely being a
> special snowflake to the distros. And for those not building product,
> it's probably just going to be too much work. I'd rather be thankful of
> Matthew's honesty about that up front instead of not saying anything,
> and it getting quietly dropped, and people being mad later.

That's fair. It's still bothersome that the answer is "we'd walk away
from you" rather than "we understand the pressure our requirement places
on you and would like to work on a solution with you."

> 
> A lot of distros specifically have policies against this kind of
> bundling as well, because of security issues like this (which was so
> very bad) - http://www.zlib.net/advisory-2002-03-11.txt
> 
> How to mitigate that kind of issue and "fleet deploy" CVEed libraries in
> these environments is definitely an open question, especially as it
> doesn't fit into the security stream and tools that distros have built
> over the last couple of decades.

Yep. That's why I'm not trying to prescribe a solution. Our upstream
solution can be pretty light-weight, and that leaves room for
downstream folks to make different choices.

Doug

> 
>     -Sean
> 



More information about the OpenStack-dev mailing list