[all] Dangerous trend toward too many release-independent components

Thomas Goirand zigo at debian.org
Tue Sep 7 22:46:30 UTC 2021

On 9/7/21 3:39 PM, Jeremy Stanley wrote:
> On 2021-09-07 11:09:45 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> since we have pinned global requirements, will these new updates
>> be included in the tests of older OpenStack releases? Is this
>> really the case right now?
> [...]
> They generally shouldn't, and most of the time can't realistically,
> have their entries altered in stable branches of the
> upper-constraints.txt file we use to pin dependency versions. To be
> able to do so would prevent them from using new features of their
> own dependencies in master branch development, since those would end
> up also needing updates in the pinned list of transitive stable
> branch constraints, which is exactly what we want to avoid.
> The workaround is to create a stable branch of the repository from
> the last version which was tagged during the cycle for the release
> which needs a fix to that independent deliverable backported. Those
> cases are rare, and basically what you would include as a stable
> distro package update for that coordinated release series anyway.


Thanks for your insights.

Basically, what you're writing above confirm what I thought: the
release-independent components are in fact not really
release-independent, and are bound to a specific release of OpenStack.
Most of the time, they aren't updated in the stable release CI.
Therefore, it would probably be wise to try to minimize the amount of
release-independent components to reflect this reality.

In fact, I was particularly confuse to realize that something like
taskflow was declared release-independent since Wallaby. Now, if I'm
told that it is loosely coupled with OpenStack, knowing that it's a key
component, I'm not sure what I should do. Should I get taskflow updated
to 4.6.2 in Wallaby, so I get bugfixes? Or is it safer to just upgrade
it for Xena?

I took Taskflow as an example (you can reply to me about Taskflow in
particular, but that's not the point I'm trying to make). But it could
have been something else (deptcollector? oslo.i18n?). What I'm trying to
say is that as a downstream consumer, it's from hard to impossible to
know what to do for the past OpenStack releases regarding these
release-independent components: should I update them or not? It is
unrealistic to hope that one can track what component has been updated
to a newer version in the stable release CI.

Therefore, if possible, I would prefer clearer, easier to track,
release-bound components with point release updates (though I understand
that it may not be possible if that's too much work and OpenStack is
getting  understaffed...).


Thomas Goirand (zigo)

More information about the openstack-discuss mailing list