git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[kolla][tripleo] python3 support for RHEL based systems


Ahoy Kolla folks,

In TripleO/RDO we've been working towards getting python3 support
ready when the next CentOS is released.  We've been working towards
getting the packaging all ready and have a basic setup working on
fedora 28. We would like to get a head start in Kolla and I've
proposed two possible solutions to support the python2/python3
transition in the container builds.  I am looking for input from the
Kolla folks on which of the two methods would be preferred so we can
move forward.

The first method is to handle the package names in the Dockerfiles themselves.

https://review.openstack.org/#/c/632156/ (kolla python3 packages)
https://review.openstack.org/#/c/624838/ (kolla WIP for fedora support
(not expected to merge))
https://review.openstack.org/#/c/629679/ (tripleo specific overrides)

IMHO think this method allows for a better transition between the
python2 and python3 packages as it just keys off the distro_python3
setting that we added as part of
https://review.openstack.org/#/c/631091/.  It was mentioned that this
might be more complex to follow and verbose due to the if/elses being
added into the Docker files.  I think the if/else complexity goes away
once CentOS7 support is dropped so it's a minor transition (as I
believe the target is Train for full python3 support).

The second method is to add in a new configuration option that allows
for package names to be overrideable/replaced. See

https://review.openstack.org/#/c/636403/ (kolla package-replace option)
https://review.openstack.org/#/c/636457/ (kolla python3 specifics)
https://review.openstack.org/#/c/624838/ (kolla WIP for fedora support
would need to be supplied to test)
https://review.openstack.org/#/c/636472/ (tripleo specific overrides)

IMHO I actually like the package-replace option for a few package
overrides.  I don't think this is a cleaner implementation for
replacing all the packages because it becomes less obvious what
packages would actually be used and it becomes more complex to manage.
This one feels more like it's pushing the complexity to the end user
and would still be problematic when CentOS8 comes out all the packages
would still need to be replaced in all the Docker files (in the next
cycle?).

My personal preference would be to proceed with the first method and
maybe merge the package-replace functionality if other would find it
beneficial.  I would be interested to hear if other think that the
second option would be better in the long term.

Thanks,
-Alex