[kolla] Let's switch to Python 3
Python 2 is going bye bye. Everyone knows that, lot of us ignores that. But we need to move on. Kolla has few patches to make use of Python3 based binary packages. One for Fedora [1], other for Ubuntu and Debian [2]. 1. https://review.openstack.org/624838 2. https://review.openstack.org/625298 But those patches are just tip of iceberg... # Types of images There are two types of images in Kolla: - binary - source ## Binaries state in distributions Binary ones are built from distribution packages. For RHEL/CentOS/OracleLinux is means RDO packages, for Ubuntu it is UCA and for Debian it is whatever is in distribution repositories. RDO ones are Python 2 based because there is no other version of Python in RHEL7 (I do not count EPEL or SCL). For Ubuntu we have a mix of Python 2 and Python 3 (from what I heard). Debian needs update to Buster (current 'testing', currently in soft freeze) and then we will get Python 3 packages (currently for Rocky). ### Pip issue On binary distributions we tend to use 'pip' from distribution packages. Which means 8.1.2 for CentOS:7, 9.0.1 for Ubuntu:bionic and 18.1 for Debian:buster. ## Source images In my opinion this type of images is most common during development cycle. Here we install Python and binaries from distribution repositories and then bootstrap latest 'pip' and use it to install all Python modules we need. For now those images are Python 2 based. # WIP plans for T cycle For T cycle we should move whatever possible to Python 3. Which means Debian:buster, Ubuntu:bionic and source images. No idea yet does it involves CentOS:7 source images as well as this would require us to use EPEL repository for Python 3. ## Always bootstrap pip Due to 'pip' issue we may need to bootstrap latest version in each type of images. This will give us simple 'pip' command in each image nevermind which version of Python is used. That saves us from dealing with "is it 'pip' or 'pip3' we need to use" thing. ## Create new variables There will be few different versions of Python in use: 2.7 (RHEL7 family), 3.6 (Ubuntu:bionic and RHEL7/EPEL), 3.7 (Debian:buster). As we tend to modify some files or need to know where Python modules are present. We may use values from 'sys.path' list for it or create 'python_path' (or similar) variable and set it per distribution/image_type. # Some kind of work items list 1. Move Debian to 'buster' release. https://review.openstack.org/612681 2. Bootstrap 'pip' in all image types. 3. Move source images to Python 3 (Debian, Ubuntu for sure, no idea yet about CentOS). 4. Move binary images to Python 3 (Debian, Ubuntu, Fedora/RHEL8) Each step will require several build/test/fix cycles. We also need to identify which images still require Python 2. # Summary I know that this mail looks a bit chaotic but I think that we need to discuss and plan what we need to do and how. And cooperate with external teams which provide binary packages (that's why Thomas and Haïkel are in Cc:). What do you think?
On 2019-02-28 20:46:19 +0100 (+0100), Marcin Juszkiewicz wrote:
Python 2 is going bye bye. Everyone knows that, lot of us ignores that. But we need to move on. [...] I know that this mail looks a bit chaotic but I think that we need to discuss and plan what we need to do and how. And cooperate with external teams which provide binary packages (that's why Thomas and Haïkel are in Cc:).
What do you think?
Please also take into account the Python2 Deprecation Timeline resolution from the OpenStack Technical Committee: https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation... Effectively, we determined that it's safe for OpenStack projects to drop Python2 testing and become Python3-only late this year, after the Train release has been tagged. See the final item in the numbered list there, "Existing projects under TC governance at the time this resolution is accepted must not drop support for Python 2 before the beginning of the U development cycle (currently anticipated for late 2019)." So please do make sure Kolla is 100% working with Python3 by the time Train releases, but keep it working with Python2 until after Train is released. -- Jeremy Stanley
Jeremy Stanley <fungi@yuggoth.org> writes:
On 2019-02-28 20:46:19 +0100 (+0100), Marcin Juszkiewicz wrote:
Python 2 is going bye bye. Everyone knows that, lot of us ignores that. But we need to move on. [...] I know that this mail looks a bit chaotic but I think that we need to discuss and plan what we need to do and how. And cooperate with external teams which provide binary packages (that's why Thomas and Haïkel are in Cc:).
What do you think?
Please also take into account the Python2 Deprecation Timeline resolution from the OpenStack Technical Committee:
https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation...
Effectively, we determined that it's safe for OpenStack projects to drop Python2 testing and become Python3-only late this year, after the Train release has been tagged. See the final item in the numbered list there, "Existing projects under TC governance at the time this resolution is accepted must not drop support for Python 2 before the beginning of the U development cycle (currently anticipated for late 2019)."
So please do make sure Kolla is 100% working with Python3 by the time Train releases, but keep it working with Python2 until after Train is released. -- Jeremy Stanley
Any code the Kolla team is building themselves should still support Python 2 under the deprecation policy, but if all of the projects that Kolla packages support Python 3, I'm not sure why we would also require them to package Python 2 versions. It might be necessary for them to use python 2 versions of some distro packages for a while, I guess. But I don't see any utility in Kolla offering its users a choice of which version of Python to use on a given platform. I would just pick the highest version number that works. Am I missing something? Maybe we need to clarify the guidelines? -- Doug
On 2019-03-01 10:31:44 -0500 (-0500), Doug Hellmann wrote: [...]
Any code the Kolla team is building themselves should still support Python 2 under the deprecation policy, but if all of the projects that Kolla packages support Python 3, I'm not sure why we would also require them to package Python 2 versions.
I didn't mean to suggest we should, only that Kolla should not drop Python 2.7 testing of the software they write until after the Train release. Artifacts they produce can support one or the other, sure, they just need to not cease being able to build from Python 2.7.
It might be necessary for them to use python 2 versions of some distro packages for a while, I guess. But I don't see any utility in Kolla offering its users a choice of which version of Python to use on a given platform. I would just pick the highest version number that works.
I think it depends on which "users" you're talking about: people who want to use images built by Kolla vs. people who want to run Kolla's tools to build images.
Am I missing something? Maybe we need to clarify the guidelines?
I don't find the guidelines unclear, so am unsure where the confusion lies. I just wanted to make sure they didn't plan to cease testing against Python2.7-based environments before the timeline we've established says that's acceptable, so that people without a Python3-supporting environment can still be assured running Kolla's tools will work to build images for the duration. -- Jeremy Stanley
Jeremy Stanley <fungi@yuggoth.org> writes:
On 2019-03-01 10:31:44 -0500 (-0500), Doug Hellmann wrote: [...]
Any code the Kolla team is building themselves should still support Python 2 under the deprecation policy, but if all of the projects that Kolla packages support Python 3, I'm not sure why we would also require them to package Python 2 versions.
I didn't mean to suggest we should, only that Kolla should not drop Python 2.7 testing of the software they write until after the Train release. Artifacts they produce can support one or the other, sure, they just need to not cease being able to build from Python 2.7.
It might be necessary for them to use python 2 versions of some distro packages for a while, I guess. But I don't see any utility in Kolla offering its users a choice of which version of Python to use on a given platform. I would just pick the highest version number that works.
I think it depends on which "users" you're talking about: people who want to use images built by Kolla vs. people who want to run Kolla's tools to build images.
Am I missing something? Maybe we need to clarify the guidelines?
I don't find the guidelines unclear, so am unsure where the confusion lies. I just wanted to make sure they didn't plan to cease testing against Python2.7-based environments before the timeline we've established says that's acceptable, so that people without a Python3-supporting environment can still be assured running Kolla's tools will work to build images for the duration. -- Jeremy Stanley
Some of the responses to your email mentioned giving users a choice about python 2 or 3 in the images. I think we agree we don't care about that, and only care that whatever software the Kolla team is writing to make, manage, and install the images retains python 2 support. -- Doug
Jeremy Stanley <fungi@yuggoth.org> writes:
On 2019-03-01 10:31:44 -0500 (-0500), Doug Hellmann wrote: [...]
Any code the Kolla team is building themselves should still support Python 2 under the deprecation policy, but if all of the projects that Kolla packages support Python 3, I'm not sure why we would also require them to package Python 2 versions.
I didn't mean to suggest we should, only that Kolla should not drop Python 2.7 testing of the software they write until after the Train release. Artifacts they produce can support one or the other, sure, they just need to not cease being able to build from Python 2.7.
It might be necessary for them to use python 2 versions of some distro packages for a while, I guess. But I don't see any utility in Kolla offering its users a choice of which version of Python to use on a given platform. I would just pick the highest version number that works.
I think it depends on which "users" you're talking about: people who want to use images built by Kolla vs. people who want to run Kolla's tools to build images.
Am I missing something? Maybe we need to clarify the guidelines?
I don't find the guidelines unclear, so am unsure where the confusion lies. I just wanted to make sure they didn't plan to cease testing against Python2.7-based environments before the timeline we've established says that's acceptable, so that people without a Python3-supporting environment can still be assured running Kolla's tools will work to build images for the duration. -- Jeremy Stanley
Some of the responses to your email mentioned giving users a choice about python 2 or 3 in the images. I think we agree we don't care about that, and only care that whatever software the Kolla team is writing to make, manage, and install the images retains python 2 support. -- Doug
Thanks for getting this conversation going. On Thu, 28 Feb 2019 at 19:46, Marcin Juszkiewicz < marcin.juszkiewicz@linaro.org> wrote:
Python 2 is going bye bye. Everyone knows that, lot of us ignores that. But we need to move on.
*pulls head out of sand*
Kolla has few patches to make use of Python3 based binary packages. One for Fedora [1], other for Ubuntu and Debian [2].
1. https://review.openstack.org/624838 2. https://review.openstack.org/625298
There is also the python3 on RHEL8 patch: https://review.openstack.org/#/c/632156/19.
But those patches are just tip of iceberg...
# Types of images
There are two types of images in Kolla:
- binary - source
## Binaries state in distributions
Binary ones are built from distribution packages. For RHEL/CentOS/OracleLinux is means RDO packages, for Ubuntu it is UCA and for Debian it is whatever is in distribution repositories.
RDO ones are Python 2 based because there is no other version of Python in RHEL7 (I do not count EPEL or SCL).
Although RHEL8 is python 3 only.
For Ubuntu we have a mix of Python 2 and Python 3 (from what I heard).
Debian needs update to Buster (current 'testing', currently in soft freeze) and then we will get Python 3 packages (currently for Rocky).
### Pip issue
On binary distributions we tend to use 'pip' from distribution packages. Which means 8.1.2 for CentOS:7, 9.0.1 for Ubuntu:bionic and 18.1 for Debian:buster.
For binary images we don't typically use pip, right - so this is just for edge cases where a package isn't available?
## Source images
In my opinion this type of images is most common during development cycle.
People use them in production too - better for CI/CD, or if you have
downstream patches.
Here we install Python and binaries from distribution repositories and then bootstrap latest 'pip' and use it to install all Python modules we need.
For now those images are Python 2 based.
# WIP plans for T cycle
For T cycle we should move whatever possible to Python 3. Which means Debian:buster, Ubuntu:bionic and source images. No idea yet does it involves CentOS:7 source images as well as this would require us to use EPEL repository for Python 3.
As Jeremy suggests, I think we may need to support both in some cases. That may not be possible for binary images - we can only use what is offered by distros - but for source images there's no reason (AFAIK) why we can't have a config option for the version of python to use. We now [1] have a distro_python3 config flag that does this. In hindsight, 'distro' might not be the most appropriate name for source images, but hey. ## Always bootstrap pip
Due to 'pip' issue we may need to bootstrap latest version in each type of images. This will give us simple 'pip' command in each image nevermind which version of Python is used. That saves us from dealing with "is it 'pip' or 'pip3' we need to use" thing.
Although that question is fairly trivial if there is a config option for the python version. I think Martin Andre would have an issue with this, given his recent work on trying to evict non-distro stuff from binary images.
## Create new variables
There will be few different versions of Python in use: 2.7 (RHEL7 family), 3.6 (Ubuntu:bionic and RHEL7/EPEL), 3.7 (Debian:buster). As we tend to modify some files or need to know where Python modules are present. We may use values from 'sys.path' list for it or create 'python_path' (or similar) variable and set it per distribution/image_type.
Also, RHEL8/CentOS8 will be 3.6, Fedora 28 is 3.7?
# Some kind of work items list
1. Move Debian to 'buster' release. https://review.openstack.org/612681 2. Bootstrap 'pip' in all image types. 3. Move source images to Python 3 (Debian, Ubuntu for sure, no idea yet about CentOS).
s/Move/Add support for/
4. Move binary images to Python 3 (Debian, Ubuntu, Fedora/RHEL8)
Each step will require several build/test/fix cycles. We also need to identify which images still require Python 2.
Time for a big table.
# Summary
I know that this mail looks a bit chaotic but I think that we need to discuss and plan what we need to do and how. And cooperate with external teams which provide binary packages (that's why Thomas and Haïkel are in Cc:).
What do you think?
W dniu 01.03.2019 o 10:43, Mark Goddard pisze:
On Thu, 28 Feb 2019 at 19:46, Marcin Juszkiewicz < marcin.juszkiewicz@linaro.org> wrote:
Python 2 is going bye bye. Everyone knows that, lot of us ignores that. But we need to move on.
*pulls head out of sand*
Kolla has few patches to make use of Python3 based binary packages. One for Fedora [1], other for Ubuntu and Debian [2].
1. https://review.openstack.org/624838 2. https://review.openstack.org/625298
There is also the python3 on RHEL8 patch: https://review.openstack.org/#/c/632156/19.
Right.
## Binaries state in distributions
Binary ones are built from distribution packages. For RHEL/CentOS/OracleLinux is means RDO packages, for Ubuntu it is UCA and for Debian it is whatever is in distribution repositories.
RDO ones are Python 2 based because there is no other version of Python in RHEL7 (I do not count EPEL or SCL).
Although RHEL8 is python 3 only.
And is not yet released.
For Ubuntu we have a mix of Python 2 and Python 3 (from what I heard).
Debian needs update to Buster (current 'testing', currently in soft freeze) and then we will get Python 3 packages (currently for Rocky).
### Pip issue
On binary distributions we tend to use 'pip' from distribution packages. Which means 8.1.2 for CentOS:7, 9.0.1 for Ubuntu:bionic and 18.1 for Debian:buster.
For binary images we don't typically use pip, right - so this is just for edge cases where a package isn't available?
From quick look it looks like 'kolla-toolbox' and 'helm-repository' install from pip everytime. But they can be changed.
# WIP plans for T cycle
For T cycle we should move whatever possible to Python 3. Which means Debian:buster, Ubuntu:bionic and source images. No idea yet does it involves CentOS:7 source images as well as this would require us to use EPEL repository for Python 3.
As Jeremy suggests, I think we may need to support both in some cases. That may not be possible for binary images - we can only use what is offered by distros - but for source images there's no reason (AFAIK) why we can't have a config option for the version of python to use. We now [1] have a distro_python3 config flag that does this. In hindsight, 'distro' might not be the most appropriate name for source images, but hey.
Kolla's code supports both Python 2 and Python 3. So we are covered when it comes to 'Python2 Deprecation Timeline' in my opinion. Images built by Kolla support whatever binaries require. For source based images we will have to keep some kind of py2/3 but imho we should clearly define which distros are py2 and which are py3 and keep that way. So for example Debian and Ubuntu will be Python 3 based for both binary and source type of images.
## Always bootstrap pip
Due to 'pip' issue we may need to bootstrap latest version in each type of images. This will give us simple 'pip' command in each image nevermind which version of Python is used. That saves us from dealing with "is it 'pip' or 'pip3' we need to use" thing.
Although that question is fairly trivial if there is a config option for the python version.
I think Martin Andre would have an issue with this, given his recent work on trying to evict non-distro stuff from binary images.
We need to take a look and probably change those images to use binaries from distros for binary types.
## Create new variables
There will be few different versions of Python in use: 2.7 (RHEL7 family), 3.6 (Ubuntu:bionic and RHEL7/EPEL), 3.7 (Debian:buster). As we tend to modify some files or need to know where Python modules are present. We may use values from 'sys.path' list for it or create 'python_path' (or similar) variable and set it per distribution/image_type.
Also, RHEL8/CentOS8 will be 3.6, Fedora 28 is 3.7?
Fedora 28 is at 3.6.8 now. For 3.7 you need Fedora 29.
# Some kind of work items list
1. Move Debian to 'buster' release. https://review.openstack.org/612681 2. Bootstrap 'pip' in all image types. 3. Move source images to Python 3 (Debian, Ubuntu for sure, no idea yet about CentOS).
s/Move/Add support for/
Will see how much work it will require and how it will complicate files.
4. Move binary images to Python 3 (Debian, Ubuntu, Fedora/RHEL8)
Each step will require several build/test/fix cycles. We also need to identify which images still require Python 2.
Time for a big table.
The good part is that 'Python2 Deprecation Timeline' requires all OpenStack projects to be Python 3 during Train so for some images it may be "mark as broken now, pester devs to comply".
On Fri, Mar 1, 2019 at 2:47 AM Mark Goddard <mark@stackhpc.com> wrote:
Thanks for getting this conversation going.
On Thu, 28 Feb 2019 at 19:46, Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> wrote:
Python 2 is going bye bye. Everyone knows that, lot of us ignores that. But we need to move on.
*pulls head out of sand*
Kolla has few patches to make use of Python3 based binary packages. One for Fedora [1], other for Ubuntu and Debian [2].
1. https://review.openstack.org/624838 2. https://review.openstack.org/625298
There is also the python3 on RHEL8 patch: https://review.openstack.org/#/c/632156/19.
Just to raise this up again, but would it be possible to try and land https://review.openstack.org/#/c/632156/ and https://review.openstack.org/#/c/639219/. We'd really like to get a head start on the python3 testing as we've got some python3 packages for fedora & stein.
But those patches are just tip of iceberg...
# Types of images
There are two types of images in Kolla:
- binary - source
## Binaries state in distributions
Binary ones are built from distribution packages. For RHEL/CentOS/OracleLinux is means RDO packages, for Ubuntu it is UCA and for Debian it is whatever is in distribution repositories.
RDO ones are Python 2 based because there is no other version of Python in RHEL7 (I do not count EPEL or SCL).
Although RHEL8 is python 3 only.
For Ubuntu we have a mix of Python 2 and Python 3 (from what I heard).
Debian needs update to Buster (current 'testing', currently in soft freeze) and then we will get Python 3 packages (currently for Rocky).
### Pip issue
On binary distributions we tend to use 'pip' from distribution packages. Which means 8.1.2 for CentOS:7, 9.0.1 for Ubuntu:bionic and 18.1 for Debian:buster.
For binary images we don't typically use pip, right - so this is just for edge cases where a package isn't available?
## Source images
In my opinion this type of images is most common during development cycle.
People use them in production too - better for CI/CD, or if you have downstream patches.
Here we install Python and binaries from distribution repositories and then bootstrap latest 'pip' and use it to install all Python modules we need.
For now those images are Python 2 based.
# WIP plans for T cycle
For T cycle we should move whatever possible to Python 3. Which means Debian:buster, Ubuntu:bionic and source images. No idea yet does it involves CentOS:7 source images as well as this would require us to use EPEL repository for Python 3.
As Jeremy suggests, I think we may need to support both in some cases. That may not be possible for binary images - we can only use what is offered by distros - but for source images there's no reason (AFAIK) why we can't have a config option for the version of python to use. We now [1] have a distro_python3 config flag that does this. In hindsight, 'distro' might not be the most appropriate name for source images, but hey.
## Always bootstrap pip
Due to 'pip' issue we may need to bootstrap latest version in each type of images. This will give us simple 'pip' command in each image nevermind which version of Python is used. That saves us from dealing with "is it 'pip' or 'pip3' we need to use" thing.
Although that question is fairly trivial if there is a config option for the python version.
I think Martin Andre would have an issue with this, given his recent work on trying to evict non-distro stuff from binary images.
## Create new variables
There will be few different versions of Python in use: 2.7 (RHEL7 family), 3.6 (Ubuntu:bionic and RHEL7/EPEL), 3.7 (Debian:buster). As we tend to modify some files or need to know where Python modules are present. We may use values from 'sys.path' list for it or create 'python_path' (or similar) variable and set it per distribution/image_type.
Also, RHEL8/CentOS8 will be 3.6, Fedora 28 is 3.7?
# Some kind of work items list
1. Move Debian to 'buster' release. https://review.openstack.org/612681 2. Bootstrap 'pip' in all image types. 3. Move source images to Python 3 (Debian, Ubuntu for sure, no idea yet about CentOS).
s/Move/Add support for/
4. Move binary images to Python 3 (Debian, Ubuntu, Fedora/RHEL8)
Each step will require several build/test/fix cycles. We also need to identify which images still require Python 2.
Time for a big table.
# Summary
I know that this mail looks a bit chaotic but I think that we need to discuss and plan what we need to do and how. And cooperate with external teams which provide binary packages (that's why Thomas and Haïkel are in Cc:).
What do you think?
I'll take a look at these today Alex. Mark On Mon, 11 Mar 2019 at 15:16, Alex Schultz <aschultz@redhat.com> wrote:
On Fri, Mar 1, 2019 at 2:47 AM Mark Goddard <mark@stackhpc.com> wrote:
Thanks for getting this conversation going.
On Thu, 28 Feb 2019 at 19:46, Marcin Juszkiewicz <
marcin.juszkiewicz@linaro.org> wrote:
Python 2 is going bye bye. Everyone knows that, lot of us ignores that. But we need to move on.
*pulls head out of sand*
Kolla has few patches to make use of Python3 based binary packages. One for Fedora [1], other for Ubuntu and Debian [2].
1. https://review.openstack.org/624838 2. https://review.openstack.org/625298
There is also the python3 on RHEL8 patch: https://review.openstack.org/#/c/632156/19.
Just to raise this up again, but would it be possible to try and land https://review.openstack.org/#/c/632156/ and https://review.openstack.org/#/c/639219/. We'd really like to get a head start on the python3 testing as we've got some python3 packages for fedora & stein.
But those patches are just tip of iceberg...
# Types of images
There are two types of images in Kolla:
- binary - source
## Binaries state in distributions
Binary ones are built from distribution packages. For RHEL/CentOS/OracleLinux is means RDO packages, for Ubuntu it is UCA and for Debian it is whatever is in distribution repositories.
RDO ones are Python 2 based because there is no other version of Python in RHEL7 (I do not count EPEL or SCL).
Although RHEL8 is python 3 only.
For Ubuntu we have a mix of Python 2 and Python 3 (from what I heard).
Debian needs update to Buster (current 'testing', currently in soft freeze) and then we will get Python 3 packages (currently for Rocky).
### Pip issue
On binary distributions we tend to use 'pip' from distribution packages. Which means 8.1.2 for CentOS:7, 9.0.1 for Ubuntu:bionic and 18.1 for Debian:buster.
For binary images we don't typically use pip, right - so this is just for edge cases where a package isn't available?
## Source images
In my opinion this type of images is most common during development
cycle.
People use them in production too - better for CI/CD, or if you have downstream patches.
Here we install Python and binaries from distribution repositories and then bootstrap latest 'pip' and use it to install all Python modules we need.
For now those images are Python 2 based.
# WIP plans for T cycle
For T cycle we should move whatever possible to Python 3. Which means Debian:buster, Ubuntu:bionic and source images. No idea yet does it involves CentOS:7 source images as well as this would require us to use EPEL repository for Python 3.
As Jeremy suggests, I think we may need to support both in some cases. That may not be possible for binary images - we can only use what is offered by distros - but for source images there's no reason (AFAIK) why we can't have a config option for the version of python to use. We now [1] have a distro_python3 config flag that does this. In hindsight, 'distro' might not be the most appropriate name for source images, but hey.
## Always bootstrap pip
Due to 'pip' issue we may need to bootstrap latest version in each type of images. This will give us simple 'pip' command in each image nevermind which version of Python is used. That saves us from dealing with "is it 'pip' or 'pip3' we need to use" thing.
Although that question is fairly trivial if there is a config option for the python version.
I think Martin Andre would have an issue with this, given his recent work on trying to evict non-distro stuff from binary images.
## Create new variables
There will be few different versions of Python in use: 2.7 (RHEL7 family), 3.6 (Ubuntu:bionic and RHEL7/EPEL), 3.7 (Debian:buster). As we tend to modify some files or need to know where Python modules are present. We may use values from 'sys.path' list for it or create 'python_path' (or similar) variable and set it per
distribution/image_type.
Also, RHEL8/CentOS8 will be 3.6, Fedora 28 is 3.7?
# Some kind of work items list
1. Move Debian to 'buster' release. https://review.openstack.org/612681 2. Bootstrap 'pip' in all image types. 3. Move source images to Python 3 (Debian, Ubuntu for sure, no idea yet about CentOS).
s/Move/Add support for/
4. Move binary images to Python 3 (Debian, Ubuntu, Fedora/RHEL8)
Each step will require several build/test/fix cycles. We also need to identify which images still require Python 2.
Time for a big table.
# Summary
I know that this mail looks a bit chaotic but I think that we need to discuss and plan what we need to do and how. And cooperate with external teams which provide binary packages (that's why Thomas and Haïkel are in Cc:).
What do you think?
W dniu 28.02.2019 o 20:46, Marcin Juszkiewicz pisze:
Python 2 is going bye bye. Everyone knows that, lot of us ignores that. But we need to move on.
Some time passed so I though that would be good to write some kind of summary. We have several patches in queue. With all of them applied we have Debian:buster using only Python3 (binary/source) in all images. There are exceptions - all images which install 'ceph-common' package (or anything depending on it) get Python 2 as a bonus. For Ubuntu:18.04 situation is similar - Python3 in all images, 'ceph-common' fetching Python 2. But there are several Py3 packages depending on Py2 ones so most of images contain two versions of Python. We got initial support for RHEL8 based containers. Not digged much into it. CentOS 7 stays at Python 2 for now.
participants (5)
-
Alex Schultz
-
Doug Hellmann
-
Jeremy Stanley
-
Marcin Juszkiewicz
-
Mark Goddard