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