[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