Project

General

Profile

Bug #56945

Updated by Ernesto Puerta over 1 year ago

h1. WIP 

 Python release lifecycle usually "spans for 5 years":https://endoflife.date/python. Python 3.6 was launched in Dec 2016 and was deprecated by Dec 2021. However "2 active Ceph releases":https://docs.ceph.com/en/latest/releases/#active-releases are still based on that Python version (Pacific and Quincy). Ideally the Python interpreter version should be picked to couple with the Ceph release, meaning that: 
 * Pacific (2021 March-2023 Jun) should have been released with Python 3.8 (2019 Oct-2024 Oct) or Python 3.9 (2020 Oct-2025 Oct) 
 * Quincy (2022 Apr-2024 Jun) should have been released with Python 3.10 (2021 Oct-2026 Oct) 

 Impediments to the above approach: 
 * "Ceph commits to support distros":https://docs.ceph.com/en/latest/start/os-recommendations/#platforms that don't follow the above cadence (e.g.: default CentOS 8 default Python is 3.6). However, in many cases these same distro provide newer versions via extra/non-official sources (EPEL, PPAs etc). 
 * While many supported distros support newer Python versions via extra packages, RPM-based distros (Fedora, CentOS, OpenSUSE, SEL) also require specific packages for each Python version (e.g.: @python3-cherrypy@ in CentOS EPEL is for 3.6, so another @python38-cherrypy@ package will be required for 3.8). Debian-like distros can share Python-only packages across multiple Python versions 


 |_.Distro              |_.Release     |_.Lifecycle     |_.Python 3.6|_.Python 3.7|_.Python 3.8|_.Python 3.9 |_.Python 3.10| 
 | *CentOS Stream*      | 8            |                | x (default)|               | x             | x             |               | 
 | *CentOS Stream*      | 9            |                |              |                            |              | x (default) |               | 
 | *Ubuntu*             | 20.04        |                | x (default)|              | x                          | x             |               | 
 | *Ubuntu*             | 22.04        |                |              |                            |              |               | x (default) | 
 | *OpenSUSE Leap*      | 15.2         | EoL (2021-12)| x (default)| (2022-01)|              |              |               |               | 
 | *OpenSUSE Leap*      | 15.3         | 2022-12                       | x (default)|              |                            | x             |               | 
 | *OpenSUSE Leap*      | 15.4         | 2023-12        | x (default)|              |              | x             | x             | 
 | *Debian*             | 10           8            |                |              | x (default)|              |               |               | 
 | *Debian*             | 11           8            |                |              |                            |              | x (default) |               | 



 

 Impediments to the above approach: 
 * "Ceph commits to support distros":https://docs.ceph.com/en/latest/start/os-recommendations/#platforms that don't follow the above cadence (e.g.: default CentOS 8 default Python is 3.6). However, in many cases these same distro provide newer versions via extra/non-official sources (EPEL, PPAs etc). 
 * While many supported distros support newer Python versions via extra packages, RPM-based distros (Fedora, CentOS, OpenSUSE, SEL) also require specific packages for each Python version (e.g.: @python3-cherrypy@ in CentOS EPEL is for 3.6, so another @python38-cherrypy@ package will be required for 3.8). Debian-like distros can share Python-only packages across multiple Python versions 


 The proposal would to perform this upgrade in a phased way: 
 * Upgrade main to Python 3.8. If successful, backport to Pacific. 
 * Upgrade main to Python 3.9. If successful, backport to Quincy. 
 * Branch @main@ should be upgraded to 3.10/3.11 as soon as available, and drop support for certain distros for Reef: CentOS 8, Ubuntu 20.04, ... 

Back