Open Stack

On Fri, 2022-03-11 at 12:26 +0000, Stephen Finucane wrote:
> tl;dr: How do we get projects using the independent release process to use the
> openstack-python3 zuul job template corresponding to the latest release?

FYI, we've opted to go with the first option below (introducing an unversioned
job template that projects using the independent release process can use). This
was achieved via [1] which should merge shortly. I've pushed a number of patches
to fix this for various oslo- and sdk-affiliated projects [2]. I trust other
teams (puppet? charms?) can handle this for their own projects :)

Cheers,
Stephen

[1] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286
[2] https://review.opendev.org/q/topic:add-python3-unversioned-jobs


> I've noticed a couple of patches like [1] popping up for oslo-affiliated projects.
> These projects are currently using the python3 zuul job templates corresponding
> to an older release (e.g. Wallaby) and the author is correctly updating them to
> use the most recent release. These initially caught me off-guard since I'm used
> to seeing a bot propose these changes but I've realized that all affected
> projects are using the "independent" release process and therefore don't receive
> a new stable branch nor related bot-proposed commits. This leaves us in a bit of
> a pickle though. There are a lot of projects using this release process, and
> there's effectively zero chance that someone is going to remember to bump the
> jobs every single release.
> 
> While some could argue that this is "working as designed", it seems important to
> me that we would be testing these projects against the supported runtimes for
> the release currently under development. As such, how should we try to address
> this? One option I see is to add a new generic 'openstack-python3-jobs' template
> which would always duplicate the jobs used for the current release. I've
> proposed that here [2]. There are some pros and cons to this approach:
> 
>  * PRO: Minimal effort from everyone.
>  * CON: The HEAD of master for each project could be broken and we'd never know
>    until some change was proposed to master (note: this is effectively the
>    status quo right now, so it's not a big break)
>  * CON: If those independent projects had an alternative to stable branches
>    (i.e. semver branches), those would eventually break as the runtimes kept
>    changing.
> 
> The other option is to extend the openstack bot to propose release bump patches
> against these independent projects. This has the inverse pro/con balance:
> 
>  * PRO: We get a regular "check-up" on the health of the project whenever these
>    patches are proposed.
>  * PRO: Long-lived stable branches should stay working
>  * CON: Lots of busy work for reviewers.
> 
> What are everyone's thoughts? I'm in favour of the first approach (generic
> 'openstack-python3-jobs' template) but the bot enhancement would also wfm. If we
> go with the first approach, we'd probably want to script something to "fix" all
> the existing independent projects rather than attempt to find and fix them
> manually.
> 
> Cheers,
> Stephen
> 
> PS: Apologies if this has been discussed previously. I clearly missed that
> discussion.
> 
> [1] https://review.opendev.org/c/openstack/os-api-ref/+/831560
> [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286