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)| | | | | | *OpenSUSE Leap* | 15.3 | 2022-12 | x (default)| | | x | | | *OpenSUSE Leap* | 15.4 | 2023-12 | x (default)| | | x | x | | *Debian* | 10 | | | x (default)| | | | | *Debian* | 11 | | | | | x (default) | | With the above table The proposal would to perform this upgrade in main, if we move a phased way: * Upgrade main to Python 3.9: 3.8. If successful, backport to Pacific. * For Reef (main), we could still support: Upgrade main to Python 3.9. If successful, backport to Quincy. ** CentOS Stream 9, ** Ubuntu 20.04 (Surprisingly, Ubuntu 22.04 doesn't support Py3.9), ** OpenSUSE Leap 15.4 ** Debian 11 * For Quincy, if we increase Python version Branch @main@ should be upgraded to 3.9, we could maintain the "currently supported distros":https://docs.ceph.com/en/latest/start/os-recommendations/#platforms: ** 3.10/3.11 as soon as available, and drop support for certain distros for Reef: CentOS Stream 8, ** Ubuntu 20.04, ** OpenSUSE Leap 15.3, ** Debian 11 ... * For Pacific: let's not make any changes (support for Debian 10 and OpenSUSE Leap 15.2 makes it complicate to upgrade). --- And additional proposal would be to get rid of external (distro-packaged) deps and: * Embed Python code in the repo (via git submodules or subtrees), * Install at build time via @pip@ (this is the way that Dashboard works for Front-end packages) This would also require modifying the method @PyModule::load@ in the file @src/mgr/PyModule.cc@ to look for packages into the local directory (via @sys.path@): @<mgr_module_path>/site-packages/@ (or similar).