Open Stack

On 2021-09-08 00:46:30 +0200 (+0200), Thomas Goirand wrote:
[...]
> 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.

Specific examples are great actually, because it at least lets us
try to formulate a specific answer and then reason about whether a
similar answer can be generally applied to other related scenarios.
So let's take taskflow in Wallaby and Xena:

The closest thing we have to a recommendation for versions of
"outside" dependencies (which is essentially what we treat
release-independent deliverables as) is the upper-constraints.txt
file on each branch of the openstack/requirements repository. In
the case of taskflow, at the moment the stable/wallaby branch upper
constraint for taskflow is 4.6.0, which is the version we indicate
all OpenStack projects should test their stable/wallaby changes
against. That entry was last updated by
https://review.opendev.org/773620 which merged to the master branch
of openstack/requirements in February, well before the coordinated
Wallaby release.

Even though the master (upcoming Xena coordinated release)
upper-constraints.txt file lists taskflow===4.6.2, we don't test
stable branch changes of OpenStack projects with that, only what
will eventually become stable/xena once the Xena cycle concludes.

> 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...).

It seems like what you're asking for is this:

https://opendev.org/openstack/requirements/src/branch/stable/wallaby/upper-constraints.txt

Or rather, that's the closest thing we have to what I think you're
requesting. If you follow the commit history of that file, you'll
see recent updates for it on the stable/wallaby branch do consist
almost entirely of stable point releases of cycle-oriented projects:

https://opendev.org/openstack/requirements/commits/branch/stable/wallaby/upper-constraints.txt

Does this help narrow the scope of concern to the point where we can
better reason about the problems or challenges you're facing?
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210907/88c57d6d/attachment.sig>