[openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements
Thierry Carrez
thierry at openstack.org
Tue Apr 19 09:48:06 UTC 2016
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.
--
Thierry Carrez (ttx)
More information about the OpenStack-dev
mailing list