Open Stack

On 04/19/2016 11:48 AM, Thierry Carrez wrote:
>> 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.

Earlier, I wrote that Gentoo was probably an exception, but reading
posts from Matthew Thode, he explained that it wasn't really a good idea
even in Gentoo to bundle libs. So let's consider that's not an option
for all distros packaging OpenStack.

> I expect in the future the one-version-of-lib-at-a-time
> will more and more be seen as a self-imposed limitation

It has always been the case that it's a self-imposed limitation, because
that's the only sane way to maintain software.

> and less as a
> distribution axiom, and next-generation distros will appear that will
> solve that limitation one way or another.

I very much doubt that distribution will attempt shooting themselves in
the foot, and allow software to use deprecated, old versions of libs,
which conflict with each other. What can be done is mitigate issues, at
most. I fail to see how hiding the issue that 2 libs are conflicting, or
that component A can't support the latest version of component B can be
seen as the "next-generation" thing that solves all troubles.

I'm very much concerned that we're here, taking the same wrong approach
of thinking that containing libs and avoid conflict will solve troubles.
That's not the case, it just hides it. We still need to make sure that
components will support the last versions of everything at the release
time, otherwise, we'll have serious issues maintaining stable branches.

If the problems is just releasing a lot of work from the release team
(and infra, as you just pointed, TTX), then I have given a list of
things we could do. These things wont IMO impact quality, and will still
allow co-instability. I'll attempt to list it again, in a more clear way:

1- stopping to propagate the global-requirements.txt versions *of
OpenStack components* to each and every project: this isn't helping
anyone anyway, since both the gate and downstream distros are going to
use the latest version.

Example:
Let every component decided what is the minimum version of oslo.utils
that it needs, but still force it to support the latest
upper-constraints.txt version.

2- stop maintaining requirements for modules which are only needed by a
single project. Simply listing it (to make sure we don't have a 2nd
component that adopts it without knowing about the first) will be
enough, and this could be done in a separate file, which would point at
the project.

Example:
Take PuLP out of global-requirements.txt, and move it to "used-by.txt"
(the name of that file can be something else):
echo "PuLP: congress" >>used-by.txt

Then let Congress decide what version it needs.

I'm not sure yet about the consequences for 3rd party libs, this will
probably require more thinking and brainstorming, but right now, it's my
strong believe that we still need to maintain key packages in the
global-requirements.txt (I'm thinking about Alembic, SQLA and such).

Would the above releasing a lot of work from both infra and release
teams? Is this "enough", or would there still be too much work? Maybe we
could give this new workflow a try for a cycle, and see how it works
out? Please, voice your concerns, share your view, etc.

Hoping the above is constructive enough,

Cheers,

Thomas Goirand (zigo)