Open Stack

On Fri, 2022-03-11 at 17:13 +0100, Előd Illés wrote:
> Thanks for bringing this up Stephen! I am not aware of such discussions, 
> though i might missed it only.
> 
> So this is about projects with 'independent release model' and their CI 
> jobs. I think it's a valid question and we should solve this somehow.
> 
> I could also imagine a new task in our release process / schedule, when the
> release team generates the new patches via some new scripts (which is 
> somewhat identical to your second option). This has the risk though that these 
> kind of patches just linger around without anyone reviewing / fixing / merging them
> (similarly like the .gitreview and TOX_CONSTRAINTS_FILE patches, which 
> should be merged as soon as possible, but in lots of projects they just remain 
> there open forever, causing errors time to time). Considering this, maybe the 2nd
> option is better but what you wrote as CON regarding special (ie. semver)
> stable branches could be really problematic (I don't know actually, so 
> we need to ask for opinions from those projects that have such stable branches 
> in their projects with independent release model).

I've thought about this more, and I don't think the issue with the special
stable branches is actually a big issue. Firstly, I've no evidence that such
things even exist so it's likely a purely theoretical issue at this point.
However, assuming these branches _do_ exist, they would have to be created
manually. There's no reason that the '.zuul.yaml' file couldn't be modified
after this was done to use the job template from the current release (i.e.
'openstack-python3-zed-jobs'), ensuring things would age gracefully. If we have
"how to request manual stable branch creation" docs somewhere, then we could
simply note this there.

I think the unversioned job is definitely the way to go now. I just need another
approver for [1] to move forward with it.

Stephen

[1] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286

> 
> Thanks,
> 
> Előd
> 
> On 2022. 03. 11. 13:26, 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? 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
> > 
> >