[charms] Can we update the Python runtimes for the 'openstack-python3-charms-jobs' template?
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.htm... [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833330/1
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.htm... [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833330/1
participants (2)
-
Alex Kavanagh
-
Stephen Finucane