Open Stack

Excerpts from Thierry Carrez's message of 2016-04-19 11:48:06 +0200:
> Thomas Goirand wrote:
> > [...]
> >  From what I understand, the biggesgt problems you're trying to solve is
> > that managing the global-reqs is really time consuming from the release
> > team point of view, and especially its propagation to individual
> > projects. There's IMO many things that we could do to improve the
> > situation, which would be acceptable from the package maintainers point
> > of view.
> 
> It's not just the release team. The machinery around syncing global 
> requirements affects QA/Infra/Stable teams as well.
> 
> > [...]
> > On 04/18/2016 02:22 PM, Chris Dent wrote:
> >> targeting an
> >> all-in-one install seems only to serve the purposes of all-in-one rpm-
> >> or deb-based installations.
> >
> > Though that's what most everyone consumes. Or are you proposing that we
> > completely stop publishing OpenStack in distros?
> 
> No, most people consume packages, but hopefully not as an all-in-one 
> installation (where you install everything on a single host).
> 
> > Remember that in distros, there's only a single version of a library at
> > any given time, at the exception of transitions (yes, in Red Hat it's
> > technically possible to install multiple versions, but the policy
> > strongly advocates against this).
> 
> Depends on the distro. Gentoo for example lets you have multiple 
> versions of libraries installed at any given time.
> 
> > [...]
> > Please take a step back. Devstack and virtualenv are for development,
> > not for production. That's not, and should not become, our target.
> 
> All-in-one installations are also for development/test/demo, not for 
> production. That should not be our target either.
> 
> 
> My point here is that we do have global dependencies for three reasons. 
> The first one is historic: because it facilitated all-in-one 
> devstack-based testing, I think we are past that one now. The second one 
> is operational: it encourages limiting the number of our dependencies 
> and the convergence across a common set of things. The third one is that 
> it facilitates the packaging work of old Linux distributions, which 
> generally have the limitation of only supporting one version of a given 
> library.
> 
> I say "old", since with the advent of containers this limitation is 
> slowly going away. Ubuntu supports snappy packaging for container-based 
> packages, for example. They could totally package OpenStack that way if 
> they wanted. I expect in the future the one-version-of-lib-at-a-time 
> will more and more be seen as a self-imposed limitation and less as a 
> distribution axiom, and next-generation distros will appear that will 
> solve that limitation one way or another.
> 
> That said, I still think we benefit from global requirements for the 
> second reason: it provides us a mechanism to encourage dependency 
> convergence. This is very important, as it limits the knowledge required 
> to operate OpenStack, facilitates contributors jumping from one code 
> base to another, provides a great checkpoint for licensing checks, and 
> reduce our overall security exposure by limiting the body of code we 
> rely on. If we dump global requirements we would have to replace it with 
> a lot of manual effort to push convergence overall.

Right, that's why I propose we keep the list of *names* as a way
to check the packages we've approved in terms of not having lots
of redundancy and for license compatibility. A new, looser, version
of the current check run when a project's requirements.txt file is
modified would be needed to look only at the name.

Doug