[all][tc] python 3.11 testing plan

Dmitriy Rabotyagov noonedeadpunk at gmail.com
Fri Aug 25 10:24:16 UTC 2023


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.
I don't think we have a capacity (and thus alignment and will among
projects) to support "bleeding edge".
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.


On Fri, Aug 25, 2023, 10:21 Thomas Goirand <zigo at debian.org> wrote:

> On 8/23/23 20:14, Jeremy Stanley wrote:
> > On 2023-08-23 10:28:48 -0700 (-0700), Ghanshyam Mann wrote:
> > [...]
> >> Can we do the same for Debian experimental version? and just keep
> >> them in our infra with the risk of unstability. That unstability
> >> risk should be fine as we are just running some non voting testing
> >> on those to test the next python version.
> > [...]
> >
> > Let's set aside for a moment that there is no "experimental" version
> > of Debian (there is an experimental package suite but it's intended
> > for use mostly with the unstable and testing versions, it's not a
> > complete distribution of Debian on its own). What we're lacking is
> > someone to put in the time and effort to get minimal Debian unstable
> > (or testing) images building reliably in diskimage-builder, added to
> > our nodepool configuration, package mirroring in place (possibly
> > cleaning up other unused distro versions to make sufficient room for
> > that), and then adding jobs.
> >
> > Unlike, say, Ubuntu LTS or Debian stable versions, unstable and
> > testing are constantly changing, getting new versions of packages,
> > and (in the case of unstable) sometimes entirely uninstallable due
> > to transition-related package conflicts. Keeping updated images for
> > that also means having someone who is going to spend some of their
> > time keeping on top of the image build logs from Nodepool, and
> > making the constant adjustments and fixes it needs so that we
> > continue to have fresh images for that platform. If volunteers step
> > forward for this sort of thing then we generally don't tell them to
> > go away, but also if they disappear for an extended period of time
> > we absolutely will delete and clean it all up.
> >
> > So it's fine to talk about how "easy" this would be, but who's
> > planning to do it?
>
> I kind of like the idea in this thread to have a venv where we would run
> the latest RC version of the interpreter. This would be lighter than
> maintaining another image, no? At least this way, this gives upstream
> OpenStack the opportunity to be closer to distros, where as currently,
> the project is lagging 1 year and 1 interpreter version behind...
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230825/863e13d5/attachment.htm>


More information about the openstack-discuss mailing list