Open Stack

On Fri, 2022-07-15 at 14:44 +0200, Radosław Piliszek wrote:
> On Fri, 15 Jul 2022 at 11:59, Thomas Goirand <zigo at debian.org> wrote:
> > Not only for the interpreter, if we could find a way to test things in
> > Debian Unstable, always, as non-voting jobs, we would see the failures
> > early. I'd love we he had such a non-voting job, that would also use the
> > latest packages from PyPi, just so that we could at least know what will
> > happen in a near future.
> 
> Well, we can have periodic and experimental, master-only jobs to test
> things on Debian unstable because it's always interesting to see the
> upcoming breakage (or better yet - be able to pinpoint it to a certain
> change happening in Debian unstable that caused it).
> 
for the nova ci we have moved centos 9 stream jobs to the periodic-weekly pipeline and
we are going to monitor it in our weekly meeting.
i dont really have any objection to adding a debian testing or debian stable based job there too.
be it in the form of a tempest job or tox job.

we dont really have the capsity either in review bandwith or ci resouce to have enstable
distros in a voting or non voting capsity on every patch i.e. check and gate pipelines.
but a weekly periodic its proably doable.


one thing we have to be carful of however is a concern i raised last cycle with extending 3.6 support.

some of the 3.6 deprecated fature were drop in 3.10 and more feature that were depfreced in later releases
are droped in 3.11. while we can try and support the newr releases 3.9 compatiable will be needed for a long
time. so if 3.11 or 3.12 is fundementaly in compatibel with 3.9 due to a libary change ectra that will be problematic
sicne cento 9 derived distro will be on 3.9 for several years to come.

i dont actully know the exact lifecycle uels for how often new centos/rhel majory reseas happen but its usuarly aroud the .6 release of the current
release that the .0 release of the next majory version happen so every 5 years or so. i really dont know the plans for rhel 10 but
for rhel9/centos 9 lifetime 3.9 will be the python version used so we need to balnce fast moving distors like debian and slow moving distors like
centos and enable both. that might mean we will ahve to drop some deps, avoid some features or utilise compatablity libs in some cases similar to
six or mock the lib vs unittest.mock

so when fixing any 3.11 incompatiablity we need to still maintain 3.8 compatiablity for zed and 3.9 compatiblity in AA+

i woudl guess it will be the CC or DD release before we coudl consdier droping 3.9 suppot but i think we could drop 3.8 in AA.


>  The job would
> only utilise the interpreter and the helper binaries (like ovs) - all
> targets I can think of are capable only of using pip-installed deps
> and not Debian packages so that part we cannot really cover reliably
> at all. If that makes sense to you, we can work towards that
> direction. The biggest issue will still be the bootability/usability
> of the infra image though.
> 
> -yoctozepto
>