Project

General

Profile

Actions

Feature #23096

closed

Update RHEL 8 packages to build with Python 3.11

Added by Brett Smith 7 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
Deployment
Target version:
Story points:
-
Release relationship:
Auto

Description

Because Arvados 3.2.0 drops support for Debian 11 and Ubuntu 20.04, our minimum Python version between those distros goes from 3.8 to 3.10 (in Ubuntu 22.04).

RHEL 8.8 AppStreams include Python 3.11. Update our RHEL 8 packages to build with this version. Write an upgrade note about this. This way, Arvados 3.2.0 can drop all support for Python 3.9, which will go EOL during the 3.2.x series.

(I would be open to upgrade to Python 3.10 or 3.12, but neither of those are available in AppStreams, so that makes the decision for us.)


Subtasks 1 (0 open1 closed)

Task #23102: Review 23096-rhel8-py311ResolvedBrett Smith08/15/2025Actions

Related issues 1 (0 open1 closed)

Blocks Arvados - Feature #23097: Update all Python modules to require 3.10, remove 3.8 and 3.9 classifiersResolvedBrett SmithActions
Actions #1

Updated by Brett Smith 7 months ago

  • Blocks Feature #23097: Update all Python modules to require 3.10, remove 3.8 and 3.9 classifiers added
Actions #2

Updated by Brett Smith 7 months ago

  • Target version set to Development 2025-08-21
  • Assigned To set to Brett Smith
  • Status changed from New to In Progress

23096-rhel8-py311 @ ec4b179c65703ecbce01afab28f2b1772ed0fa60

build-packages-rocky8: #1122

developer-run-tests-doc-sdk-java-R: #2247 (for doc changes)

  • All agreed upon points are implemented / addressed. Describe changes from pre-implementation design.
    • Yes
  • Anything not implemented (discovered or discussed during work) has a follow-up story.
    • N/A
  • Code is tested and passing, both automated and manual, what manual testing was done is described.
    • See above. In the build-packages console output, in the package tests, you can see that when installing Arvados Python packages brings in Python 3.11. Also reviewed documentation manually.
  • Tested code incorporates recent main branch changes.
    • Yes
  • New or changed UI/UX and has gotten feedback from stakeholders.
    • N/A
  • Documentation has been updated.
    • Yes
  • Behaves appropriately at the intended scale (describe intended scale).
    • No change in scale
  • Considered backwards and forwards compatibility issues between client and server.
    • N/A - Does raise the minimum version of RHEL 8 we support, in a way that we're okay with (it's more than two years old, very close to Debian 12 in both age and packaged software).
  • Follows our coding standards and GUI style guidelines.
    • N/A
Actions #3

Updated by Brett Smith 7 months ago

  • Subtask #23102 added
Actions #4

Updated by Tom Clegg 7 months ago

Should the upgrade notes also mention that you need at least 9.2 if you're on the 9 series?

With this the modules_to_enable doc template feature is unused. But we'll need it again to raise our minimum Python version without dropping distro support, so we're keeping it around. Is that right?

Rest LGTM.

Actions #5

Updated by Tom Clegg 7 months ago

Is the postgresql:10 → postgresql:15 change just because 15 is the minimum version in 8.8, 9.2?

Actions #6

Updated by Tom Clegg 7 months ago

Tom Clegg wrote in #note-5:

Is the postgresql:10 → postgresql:15 change just because 15 is the minimum version in 8.8, 9.2?

Hm, I guess not because alma 9.2 and 9.6 both ship postgresql 13.

Actions #7

Updated by Brett Smith 7 months ago

Tom Clegg wrote in #note-4:

Should the upgrade notes also mention that you need at least 9.2 if you're on the 9 series?

No, because this isn't a change since the last release. 3.2.0 is the first version with RHEL 9 support.

With this the modules_to_enable doc template feature is unused. But we'll need it again to raise our minimum Python version without dropping distro support, so we're keeping it around. Is that right?

Honestly, I don't know. Behold:

$ docker run --rm -ti rockylinux:8-minimal
bash-4.4# microdnf install dnf
[…]
Complete.
bash-4.4# dnf module list | grep python3
python36             3.6 [d]         build, common [d]                        Python programming language, version 3.6
python38             3.8 [d]         build, common [d]                        Python programming language, version 3.8
python39             3.9 [d]         build, common [d]                        Python programming language, version 3.9

Note Python 3.11 is not on this list. The release notes document that it is available from appstreams, but it no longer requires you to enable a module to get it. I do not know if they'll be using this same strategy going forward, or if future versions of Python might require a module again, or what. So… I guess I'm hedging against this uncertainty?

Is the postgresql:10 → postgresql:15 change just because 15 is the minimum version in 8.8, 9.2?

It was purely opportunistic. Similarly to the Python upgrade, this bump brings the RHEL 8 versions more in line with other distributions we're supporting like Debian 12. (I did not make any change to RHEL 9 here.) However, note also that the only place we actually use this in is the package test Docker image. arvados-api-server's dependency on PostgreSQL is unversioned and that is not affected by this branch:

% rpm -qRF arvados-api-server-3.2.0\~dev20250812154933-1.x86_64.rpm | grep postgres
postgresql
postgresql-devel
Actions #8

Updated by Tom Clegg 7 months ago

Brett Smith wrote in #note-7:

It was purely opportunistic. Similarly to the Python upgrade, this bump brings the RHEL 8 versions more in line with other distributions we're supporting like Debian 12. (I did not make any change to RHEL 9 here.) However, note also that the only place we actually use this in is the package test Docker image. arvados-api-server's dependency on PostgreSQL is unversioned and that is not affected by this branch:

I see, that enables the postgresql:15 module when we're testing whether our packages can actually be installed on rh8, we aren't actually demanding that version in actual deployments.

LGTM, thanks for the clarifications.

Actions #9

Updated by Brett Smith 7 months ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF