Open Stack

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 at 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 at 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)
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230823/36a73202/attachment-0001.htm>