Open Stack

On Fri, Jul 15, 2022, at 7:14 AM, Sean Mooney wrote:
> 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.

Removals for 3.10 are captured here: https://docs.python.org/3/whatsnew/3.10.html#removed and for 3.11 at https://docs.python.org/3.11/whatsnew/3.11.html#removed if anyone is curious.

Considering the number of projects that appear to be currently running python3.8 and 3.10 job successfully, the major problem here is likely going to be if/when our dependencies decide to stop supporting older pythons. Often times we can get away with simply having different requirements for different versions of python, but that may not always work for each dependency.

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

Python 3.9 EOL is October 2025. With 3.6 we saw many libraries maintain compatibility until the EOL for that version. I'm hopeful that trend will continue and this will largely be a non issue for us.

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