<div dir="auto">While I do like idea of testing more python versions using pyenv, I don't share the idea that OpenStack as a project must match the base requirements that are shipped in any given distro, especially when talking about ones that are still in development.<div dir="auto">I don't think we have a capacity (and thus alignment and will among projects) to support "bleeding edge".</div><div dir="auto">At the end, you can have any python version needed on Debian or any other distro with pyenv as well, so it should not be a problem or a blocker to use OpenStack on distros that do not pre-ship supported by OpenStack python versions.</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 25, 2023, 10:21 Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 8/23/23 20:14, Jeremy Stanley wrote:<br>
> On 2023-08-23 10:28:48 -0700 (-0700), Ghanshyam Mann wrote:<br>
> [...]<br>
>> Can we do the same for Debian experimental version? and just keep<br>
>> them in our infra with the risk of unstability. That unstability<br>
>> risk should be fine as we are just running some non voting testing<br>
>> on those to test the next python version.<br>
> [...]<br>
> <br>
> Let's set aside for a moment that there is no "experimental" version<br>
> of Debian (there is an experimental package suite but it's intended<br>
> for use mostly with the unstable and testing versions, it's not a<br>
> complete distribution of Debian on its own). What we're lacking is<br>
> someone to put in the time and effort to get minimal Debian unstable<br>
> (or testing) images building reliably in diskimage-builder, added to<br>
> our nodepool configuration, package mirroring in place (possibly<br>
> cleaning up other unused distro versions to make sufficient room for<br>
> that), and then adding jobs.<br>
> <br>
> Unlike, say, Ubuntu LTS or Debian stable versions, unstable and<br>
> testing are constantly changing, getting new versions of packages,<br>
> and (in the case of unstable) sometimes entirely uninstallable due<br>
> to transition-related package conflicts. Keeping updated images for<br>
> that also means having someone who is going to spend some of their<br>
> time keeping on top of the image build logs from Nodepool, and<br>
> making the constant adjustments and fixes it needs so that we<br>
> continue to have fresh images for that platform. If volunteers step<br>
> forward for this sort of thing then we generally don't tell them to<br>
> go away, but also if they disappear for an extended period of time<br>
> we absolutely will delete and clean it all up.<br>
> <br>
> So it's fine to talk about how "easy" this would be, but who's<br>
> planning to do it?<br>
<br>
I kind of like the idea in this thread to have a venv where we would run <br>
the latest RC version of the interpreter. This would be lighter than <br>
maintaining another image, no? At least this way, this gives upstream <br>
OpenStack the opportunity to be closer to distros, where as currently, <br>
the project is lagging 1 year and 1 interpreter version behind...<br>
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
<br>
</blockquote></div>