[openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements
doug at doughellmann.com
Tue Apr 19 12:45:18 UTC 2016
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
> 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.
More information about the OpenStack-dev