Open Stack

 ---- On Tue, 15 Mar 2022 11:29:45 -0500 Stephen Finucane <stephenfin at redhat.com> wrote ----
 > 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 :)

Sorry for seeing this thread late.

I think testing with latest is no different than updating them manually to the latest
release template either by bot or manually. As we use the constraint and add a
compatible version of these independent repos for each OpenStack release, I don't
think we have any case where new future version is not tested with a supported
runtime where that version will be used/documented as the compatible version for
XYZ OpenStack release. So +1 on option1.

Now thinking on this case also, these release-specific templates are causing more issues.
For example:
1. This case of independent releases repo
2. If bot missed proposing patches for some reason (like format. other release model or so) or patches
are not merged then we missed testing such repo with defined testing runtime.
3. branchless repo like PBR, Tempest has to test py version explicitly as they cannot use these
release-wise templates.

With all these issues should we just get rid of these release-specific templates and have this generic
template 'openstack-python3-jobs' with the latest testing runtime for master code testing and when
we cut the stable branch then we pin a version of this template with help of the branch variant in the
template definition (no list of jobs in that template as we cannot use branch variant for template). It
means we are cutting a new stable for OpenStack so let's pin the testing template also for that branch
(pin the same template as openstack-zuul-jobs are branchless) and branch variant can help us here.
And for the new master, move the current template to the latest testing runtime. This helps to avoid all
these bot patches and missing the latest testing running in the above-mentioned cases.
One drawback for this is we have to remember and make sure we pin this same template when cut stable.
But that effort is no different than defining the new template per release each time.

We made these release-specific templates to be very explicit in testing but it leads to testing old testing runtime
due to mentioned issues. Making them controllable in a central place helps to avoid that and also avoid these bot
patches and reviews in each repo. 

WIP Example: https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833892

Should we re-consider that option? 

-gmann

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