On Fri, 15 Feb 2019 at 23:29, Alex Schultz aschultz@redhat.com wrote:
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
Thanks for bringing this up Alex. I tend to agree with your thinking that although the package-replace option looks cleaner, it adds hidden complexity. The if/else approach is a bit of an eyesore now, but should not be present for long. My vote is for the first option. Mark