<div dir="ltr">I think the problem here isn't technical in nature. We're all technical folks, we can get python running in CI, any version we want. I have no doubt about that. There's the question as to if OpenDev has the capacity for this work; but that's not what I want to address here. <div><br></div><div>It's about prioritization and time management. Any change we make to increase the matrix -- especially increasing it to include software that is newer with potentially breaking changes -- has a direct cost in terms of developer time to troubleshoot, fix, and wait while those fixes merge. This is the direct trade-off made.</div><div><br></div><div>On top of that, we already run a set of periodic jobs on things like stable/ branches which don't get as much attention as they should.</div><div><br></div><div>All this to say, regardless of technical issues, I do not think we have the capacity to run python versions in test, such as 3.12.</div><div><br></div><div>Thanks,</div><div>Jay Faulkner</div><div>Ironic PTL</div><div>TC Vice Chair</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 23, 2023 at 8:46 AM <<a href="mailto:smooney@redhat.com">smooney@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">On Wed, 2023-08-23 at 15:56 +0200, Thomas Goirand wrote:<br>
> Hi Sean,<br>
> <br>
> Thanks for taking the time to answer me in this tread.<br>
> <br>
> On 8/23/23 13:07, <a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a> wrote:<br>
> > On Wed, 2023-08-23 at 09:10 +0200, Thomas Goirand wrote:<br>
> > > On 8/22/23 19:26, Tony Breeds wrote:<br>
> > > > Using testing would partially address some of this<br>
> > > > but it's still a pretty big ask.<br>
> > > <br>
> > > The problem with testing, is that it gets he latest interpreter version<br>
> > > *AFTER* we solve all the bugs. What I'm asking for, is that we have the<br>
> > > needed infrastructure so we can check for incompatibility *before* they<br>
> > > actually affect us. This means testing using the non-default Python<br>
> > > version when it's uploaded to Unstable.<br>
> > right unfortunetly as you are aware we use eventlet and other deps that need to have<br>
> > supprot for the latest python before we can actully use it.<br>
> <br>
> Right, and that's precisely the type of things which I would like to <br>
> detect early with this type of setup.<br>
> <br>
> > i mention eventlet beacuse its the dep that is most sensitive to python version changes<br>
> > because of how it works and the dep that would be the harderest for us to remove.<br>
> <br>
> Yeah, and eventlet breaking at all minor python release is also one of <br>
> the reason why I would love to see it go away from OpenStack... (let's <br>
> not have this conversation again now though...).<br>
> <br>
> > realistically this is not really something i think we can cahase with<br>
> > our current upstream capacity.<br>
> <br>
> Saying something like this is equivalent to say: sorry Thomas, you'll <br>
> continue to be on your own fixing Python upgrades. This doesn't work, <br>
> and doesn't scale, please find another answer...<br>
> <br>
> > having said that we did just recently merge the devstack venv support<br>
> > and tools like <a href="https://github.com/pyenv/pyenv" rel="noreferrer" target="_blank">https://github.com/pyenv/pyenv</a> exist.<br>
> > so if adding debian unstable or testing is not an option and peopel were willing to develop a job<br>
> > (devstack or tox) that worked with pyenv on say ubuntu 22.04 we could in theory test any python version<br>
> > we wanted without the need to mirror fast moving repo to afs.<br>
> <br>
> Well, adding venv capacity doesn't mean you'll have the latest Python <br>
> interpreter available. The only way to do that, is to actually either <br>
> use Unstable, or build it yourself. The former is probably easier...<br>
thats what pyvenv does<br>
<br>
it will compile a release into a venv for you which cna then be used to run tox.<br>
now that devstack supprot installing in a global virtual env we shoudl be able to leverage<br>
that capablity to test with other interperest via pyenv if that is some we need to do.<br>
<br>
that would allow use to test upstrem python release even before they are packaged in a distro.<br>
my concern is we need to invenst a lot in our ci stabelity  and we need to be careful with our<br>
capacity. both the capsity of the ci and of human attention span.<br>
<br>
we have recently had alot of issue with ci that fortunely have been improving in the last<br>
few days but im not really sure how would creat and maintain these py-next jobs beyond what we have<br>
previously been doing. <br>
<br>
> <br>
> Cheers,<br>
> <br>
> Thomas Goirand (zigo)<br>
> <br>
> <br>
<br>
<br>
</blockquote></div>