Open Stack

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)
> 
>