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

Chris Dent cdent+os at anticdent.org
Tue Apr 19 15:10:12 UTC 2016

On Tue, 19 Apr 2016, Jeremy Stanley wrote:

> Could just be that my beard has gotten a little too grey, but I
> still very much prefer using stabilized software packaged by
> traditional Linux distributions or similar Unix derivatives and
> covered under security patched backports. My hope has always been
> that as the rapid pace of development at the center of OpenStack
> starts to cool (and as the press moves on and OpenStack becomes a
> lot more boring to talk about), we'll approach the sort of ecosystem
> stabilization needed to make that less awkward downstream.

Agreed that would be nice to have, but I think we are quite a long
way from it and from my standpoint our efforts to reach a state of
quality that then allows for that stabilisation is hampered by the
time spent on co-installability.

Of course that position on quality is highly dependent on where
you're standing.

But yes: Once a tool becomes a standard piece of infrastructure then
packages totally rock.

> Running a production system from a bunch of discrete containers each
> with their own random versions of embedded libraries either getting
> upgraded willy-nilly to the latest releases or lagging/missing
> critical security patches is a regression to the bad old days when
> we didn't have reliable package management. I feel like many of the
> people pushing this idea simply didn't get to experience the pain it
> causes the first time around and won't believe their peers who lived
> through it.

I feel like I have to respond to this, because I'm one pushing this (at
least in this thread). I'll try not to take umbrage. I've been running
Unix systems, in production, since '91. When RPMs came along they were
an absolute godsend and anything that was stable and wasn't already
packaged we packaged. We automated all our builds and deploys and
packages made it rock. It was great.


This thread is about removing the clamps that co-installability
has on the velocity of OpenStack _development_ and (perish the term)
independent innovation.

If we want to accelerate that velocity _and_ people use OpenStack
want to use modern OpenStack there are ways for that to happen: One
of them is to be fully buzzword compliant with your devops brostars
down at the ok container cluster.

People don't have to use that stuff. They can lag and get plenty of

What I would like to see is that not only do packages lag master
(they already do to some extent) but that requirements
co-installability resolution also lags master. At master we should
be building the future; yes, with chaos. That chaos should be
resolved in a stabilizing process, driven by those with a need for

We need to decouple some of the constraints.

Chris Dent               (¨s¡ã¡õ¡ã)¨s¦à©ß©¥©ß            http://anticdent.org/
freenode: cdent                                         tw: @anticdent

More information about the OpenStack-dev mailing list