Open Stack

On Wed, 2023-10-11 at 19:19 +0200, Dmitriy Rabotyagov wrote:
> To be fair, all these arguments were also raised during the 2023.2
> development cycle. With additional one - we will be not able to drop
> support during non-SLURP release without breaking upgrades/compatibility
> between SLURPs. A decision was taken to keep py3.8 back then with
> acknowledgement of that fact.
> 
> Now, when 2023.2 has been released with py3.8 support, from my
> perspective there is really no way it can be removed until 2024.1 without
> breaking someone's upgrades.
> 
> Despite I agree with your arguments, TC has quite explicitly stated that
> deprecations should not take place in non-SLURP releases according to [1]
deprecateion are allowed in non slurps we just cant remove supprot for a depreaction
that has not been release in slurp. ingoring  that for a moment the deprecation poilcy
only applies to aplciation feature we have never applied it to runtimes or minium python
version.
> and I believe that reasons and background in this resolution are still
> valid and should be respected, despite how inconvenient it might be
> sometimes. As also platform consumers rely on that and plan their
> maintenance and further work based on promises that are being made by
> community.
> 
> In case a key library drops support for py3.8 then I believe we will need
> to leverage upper-constraints to set the version back for the library to
> the one which supports py3.8. Either for all python versions, or solely for
> py3.8, like we already did for py3.6 and py3.8 back in Xena/Yoga.
> 
> [1]
> https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html#details
> 
> On Wed, Oct 11, 2023, 15:45 Brian Rosmaita <rosmaita.fossdev at gmail.com>
> wrote:
> 
> > I thought about this issue some more after yesterday's TC meeting, and
> > tried to articulate why I think keeping python 3.8 support for 2024.1 is
> > a bad idea on the patch:
> > 
> > https://review.opendev.org/c/openstack/governance/+/895160
> > 
> > I don't know if my argument there will change anyone's mind, but since a
> > lot of people have already voted on the gerrit review, I wanted to make
> > sure that people are at least aware of it, to wit:
> > 
> > I just don't see that py38 support for 2024.1 makes sense. It's not a
> > default version in Ubuntu 22.04, Debian 12, Debian 11, CentOS Stream 9,
> > or Rocky Linux 9, which are the distros specifically called out in the
> > current 2024.1 PTI that this proposal is patching.
> > 
> > While we can use Ubuntu 20.04 to run unit tests, we can't run master
> > (2024.1 development) devstack in it, so it doesn't seem to me that
> > Ubuntu 20.04 is a distribution that we can feasibly use for meaningful
> > 2024.1 testing. This implies, in my opinion, that there is a solid
> > reason for dropping python 3.8 support in advance of it going EOL, as
> > required by [0].
> > 
> > Looking at the Python Update Process resolution [1], python 3.8 does not
> > meet the three criteria set out in the "Unit Tests" section:
> > 
> > 1. it's not the latest version of Python 3 available in any distro we
> > can feasibly use for testing
> > 2. It's not the default in any of the Linux distros identified in the
> > 2024.1 PTI
> > 3. It isn't used to run integration tests at the beginning of the 2024.1
> > (Caracal) cycle
> > 
> > Add to that the fact that libraries are beginning to drop support [2],
> > add further that py38 will go EOL roughly 6 months after the 2024.1
> > release (no more security updates), I don't see a reason to wait until a
> > key library forces us to make a change during the development cycle. I'd
> > prefer to do it now.
> > 
> > [0]
> > 
> > https://governance.openstack.org/tc/reference/pti/python.html#specific-commands
> > [1]
> > 
> > https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html#unit-tests
> > [2] https://review.opendev.org/c/openstack/requirements/+/884564
> > 
> >