<div dir="ltr"><div dir="ltr">Just adding that Ubuntu 23.04 (lunar) shipped with py3.11 and 2023.1 (antelope) packages, and the UCA for 2023.1 on Ubuntu 22.04 (jammy) was py3.10, so 2023/1/antelope is tested on both. Mantic (Ubuntu 23.10) looks like it will be py3.11 again, so bobcat will be on both py3.10 and py3.11, and for 24.04 (the next LTS) may well be py3.12.<div><br></div><div>So, like Thomas, we're usually a python or 2 ahead of the 'official' supported version upstream; i.e. at this point, pretty much everything that's packaged in Debian and Ubuntu at least module imports without failures on py3.11; and 'probably' works from a tempest perspective. But obviously, we don't test everything to the depth that upstream does, so perhaps that point is a bit moot.</div><div><br></div><div>A thought did occur to me though: as container based/docker/k8s solutions to the control plane are becoming more used, it's likely that the official python test might be the important data point as the container build would (from a risk perspective) more likely select the official supported python version; the host's python that the containers are run on becomes largely irrelevant. In this situation, upstream "next python version" testing becomes all the more important.</div><div><br></div><div>Cheers</div><div>Alex (tinwood)</div><div><br></div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 22 Aug 2023 at 17:27, Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com">gmann@ghanshyammann.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"> ---- On Tue, 22 Aug 2023 09:05:56 -0700 Thomas Goirand wrote --- <br>
> On 8/21/23 20:16, Ghanshyam Mann wrote:<br>
> <br>
> > Hi All,<br>
> <br>
> > <br>
> <br>
> > Some of you are part of discussion for python 3.11 testing but If you are not aware of it,<br>
> <br>
> > below is the plan for python 3.11 testing in OpenStack.<br>
> <br>
> > <br>
> <br>
> > Non voting in 2023.2<br>
> <br>
> > -------------------------<br>
> <br>
> > You might have seen that python 3.11 job is now running as non voting in all projects[1].<br>
> <br>
> > Idea is to run it as non voting for this (2023.2) cycle which will give projects to fix the issue and make<br>
> <br>
> > it green. As it is running on debian (frickler mentioned the reason of running it in debian in gerrit[2]), it<br>
> <br>
> > need some changes in bindep.txt file to pass. Here is the example of fix[3] which you can do in your<br>
> <br>
> > project also.<br>
> <br>
> > <br>
> <br>
> > Voting in 2024.1<br>
> <br>
> > --------------------<br>
> <br>
> > In next cycle (2024.1), I am proposing to make py3.11 testing mandatory [4] and voting (automatically<br>
> <br>
> > via common python job template). You need to fix the failure in this cycle otherwise it will block the<br>
> <br>
> > gate once the next cycle development start (basically once 891238 is merged).<br>
> <br>
> > <br>
> <br>
> > [1] <a href="https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891227/5" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891227/5</a><br>
> <br>
> > [2] <a href="https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891146/1" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891146/1</a><br>
> <br>
> > [3] <a href="https://review.opendev.org/c/openstack/nova/+/891256" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/nova/+/891256</a><br>
> <br>
> > [4] <a href="https://review.opendev.org/c/openstack/governance/+/891225" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/governance/+/891225</a><br>
> <br>
> > [5] <a href="https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891238" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/891238</a><br>
> <br>
> > <br>
> <br>
> > -gmann<br>
> <br>
> <br>
> <br>
> Hi,<br>
> <br>
> <br>
> <br>
> This is very nice, though, IMO, it's too late. Bookworm was released <br>
> <br>
> with OpenStack Zed, to which I already added Python 3.11 support (if you <br>
> <br>
> guys have some patches to add on top, let me know, but as much as I <br>
> <br>
> know, it was already functional).<br>
> <br>
> <br>
> <br>
> So now, the current plan is to ... test on py3.11. Yeah, but from the <br>
> <br>
> Debian perspective, we're already on Python 3.12. The RC1 is already in <br>
> <br>
> Debian Experimental, and I expect 3.12 to reach Unstable by the end of <br>
> <br>
> this year. Once again, I'll be the sole person that will experimenting <br>
> <br>
> all the troubles. It's been YEARS like this. It's probably time to <br>
> <br>
> address it, no?<br>
> <br>
> <br>
> <br>
> I'd really love it, if we could find a solution so that I stop to be the <br>
> <br>
> only person getting the shit in this world. :)<br>
> <br>
> <br>
> <br>
> What would be awesome, would be to run Debian Unstable, with the latest <br>
> <br>
> interpreter, as non-voting jobs.<br>
> <br>
<br>
Thanks Zigo for you testing and effort, that is really appreciated. <br>
<br>
I like the idea of testing the 3.12 in advance even with RC release. Also, as you mentioned<br>
we will be testing it in advance as non voting so doing it on Debian experimental version<br>
is not bad idea. this will give projects more time to fix the issues. And once we have stable<br>
version of distro having v3.12 then we can switch the job to that distro.<br>
<br>
I think ubuntu also going to package it in ~Nov/Dec time so that also one option<br>
to add it as non voting. <br>
<br>
-gmann<br>
<br>
> <br>
> <br>
> Your thoughts?<br>
> <br>
> <br>
> <br>
> Cheers,<br>
> <br>
> <br>
> <br>
> Thomas Goirand (zigo)<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Alex Kavanagh<div><span style="font-size:small">OpenStack Engineering - Canonical Ltd</span><br></div></div></div></div></div></div>