<div dir="ltr"><div>Hi Stephen</div><div><br></div><div>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.</div><div><br></div><div>Therefore:<br></div><div><br></div><div>> That is, the 'openstack-python3-charms-jobs' release will now be updated at the start of each new<br>
release to test against the same runtimes proposed for this new release.</div><div><br></div><div>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.</div><div><br></div><div>I'll add some comments to the review.  Thanks very much for raising this, and for the patch going forward.</div><div><br></div><div>Cheers</div><div>Alex.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 11, 2022 at 12:39 PM Stephen Finucane <<a href="mailto:stephenfin@redhat.com">stephenfin@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Related to the "Independent release jobs are still using old release job<br>
templates" email I just sent [1], I've proposed a change [2] that would modify<br>
the 'openstack-python3-charms-jobs' job template so that it mimics the behaviour<br>
of the proposed 'openstack-python3-jobs' template. That is, the 'openstack-<br>
python3-charms-jobs' release will now be updated at the start of each new<br>
release to test against the same runtimes proposed for this new release.<br>
However, frickler has noted that the use of older runtimes for the charms jobs<br>
may in fact be intentional. Could someone from the charms team please weigh in<br>
on [2]. If this is in fact intentional, it would be good to add a note to the<br>
job template indicating this fact to prevent people like me breaking it in the<br>
future :)<br>
<br>
Cheers,<br>
Stephen<br>
<br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027676.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027676.html</a><br>
[2] <a href="https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833330/1" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833330/1</a><br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Alex Kavanagh - Software Engineer<div><span style="font-size:small">OpenStack Engineering - Data Centre Development - Canonical Ltd</span><br></div></div></div></div></div>