Hi Stephen

Your email/patch comes at an interesting moment for us.  We currently updating our charms from a time-series release, which happens just after the main OpenStack releases, to an OpenStack version released charm.  e.g. in April we would 'normally' have released a charm set called 22.04 which covered everything from bionic-queens (really!) to focal/jammy-yoga.  Instead, we will be releasing a 'yoga' release of the charms set, that supports focal-wallaby, focal-yoga and jammy-yoga.

Therefore:

> That is, the 'openstack-python3-charms-jobs' release will now be updated at the start of each new
release to test against the same runtimes proposed for this new release.

This will be ideal for the charms project, I think.  This means that the next cycle of charms will support the runtimes that the next cycle of OpenStack supports, which in principle lines up nicely.  The only caveat is that each release of charms needs to support the previous release (from an upgrade perspective) which makes it a little more complex to consider - e.g. ussuri 'straddles' bionic and focal, so would need to test against py36, py37, py38.

I'll add some comments to the review.  Thanks very much for raising this, and for the patch going forward.

Cheers
Alex.






On Fri, Mar 11, 2022 at 12:39 PM Stephen Finucane <stephenfin@redhat.com> wrote:
Related to the "Independent release jobs are still using old release job
templates" email I just sent [1], I've proposed a change [2] that would modify
the 'openstack-python3-charms-jobs' job template so that it mimics the behaviour
of the proposed 'openstack-python3-jobs' template. That is, the 'openstack-
python3-charms-jobs' release will now be updated at the start of each new
release to test against the same runtimes proposed for this new release.
However, frickler has noted that the use of older runtimes for the charms jobs
may in fact be intentional. Could someone from the charms team please weigh in
on [2]. If this is in fact intentional, it would be good to add a note to the
job template indicating this fact to prevent people like me breaking it in the
future :)

Cheers,
Stephen

[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027676.html
[2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833330/1




--
Alex Kavanagh - Software Engineer
OpenStack Engineering - Data Centre Development - Canonical Ltd