Python… To use 2.7 or to go for 3.x? To “be compatible” or to “use fancy new features”. Next year Python 2 gets finally unsupported upstream.
Kolla state
Kolla can run under Python 2.7 or 3.x and results will be the same. All those container images containing OpenStack components and whatever needed to get them running. But so far all of those images will use Python 2.7 inside…
I proposed to take care of it during Train cycle (we are at Stein now). Then we had a meeting and decided — let us do that in Stein! If I only knew how many issues it will bring…
Cleaning/refactoring
First some cleaning and refactoring:
- debian/ubuntu: drop mysql compat stuff, unify on openssl 1.1
- openstack-base: drop pika-pool
- Introduce ‘get_pip’ macro
- helm-repository: drop unused os_client_config variable
Distribution handling
Then created new variable to keep which exactly version of Python 3: distro_python_version. And then used wherever needed.
In meantime we got support for Red Hat Enterprise Linux 8 distribution. Where Python 3 is the only version available.
Finally we moved Ubuntu to use Stein UCA which also switched us to Python 3 in several images.
CI failures
And then hell gates opened…
We moved our CI jobs from Ubuntu 16.04 ‘xenial’ to Ubuntu 18.04 ‘bionic’. OMG. So many failures. When Mark Goddard found out why (too old ‘setuptools’) we had to pile up fixes to get CI back into working state.
Nova images were failing. Turned out that Debian/Ubuntu ‘qemu’ package is no longer metapackage but useless dummy. And then it brought ‘armv6l’ architecture to Nova so it started failing. There were three different patches to handle it and problem got solved.
OracleLinux image got repository information files renamed. And as we edit them we had to adapt.
Python 3 got enabled in another set of images.
Changing other projects
Kolla uses other projects, right? Are they Python 3 ready?
Had to patch several ones:
- bifrost (and test their patch)
- ironic
- karbor
- kuryr-libnetwork
- monasca (api and persister)
- vmtp
Some of those changes were requirements updates to mark “Python 2 only” components (enum34, functools32, UcsSdk) or getting rid of Unicode characters from files which should be be US-ASCII.
Bifrost one cleaned situation as we are using it within virtualenv so Python packages were going crazy. Now they handle it ;D
Current status
The most important patch switching all image to Python 3 for Debian/Ubuntu is still in review. Waiting for karbor fix getting merged and CentOS 7/OracleLinux 7 builds getting working again.
We also moved to Debian ‘buster’ release. It is now in ‘freeze’ state so no big changes allowed and provides us with many updates making Debian/Ubuntu blocks easy.
Python 2 stays :(
There are few images where we still have Python 2. Anything related to Ceph has it because Debian/Ubuntu ‘ceph-common’ package depends on Py2 packages. We install Py3 ones there.