<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 15 Feb 2019 at 23:29, Alex Schultz <<a href="mailto:aschultz@redhat.com">aschultz@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ahoy Kolla folks,<br>
<br>
In TripleO/RDO we've been working towards getting python3 support<br>
ready when the next CentOS is released.  We've been working towards<br>
getting the packaging all ready and have a basic setup working on<br>
fedora 28. We would like to get a head start in Kolla and I've<br>
proposed two possible solutions to support the python2/python3<br>
transition in the container builds.  I am looking for input from the<br>
Kolla folks on which of the two methods would be preferred so we can<br>
move forward.<br>
<br>
The first method is to handle the package names in the Dockerfiles themselves.<br>
<br>
<a href="https://review.openstack.org/#/c/632156/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/632156/</a> (kolla python3 packages)<br>
<a href="https://review.openstack.org/#/c/624838/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/624838/</a> (kolla WIP for fedora support<br>
(not expected to merge))<br>
<a href="https://review.openstack.org/#/c/629679/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/629679/</a> (tripleo specific overrides)<br>
<br>
IMHO think this method allows for a better transition between the<br>
python2 and python3 packages as it just keys off the distro_python3<br>
setting that we added as part of<br>
<a href="https://review.openstack.org/#/c/631091/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/631091/</a>.  It was mentioned that this<br>
might be more complex to follow and verbose due to the if/elses being<br>
added into the Docker files.  I think the if/else complexity goes away<br>
once CentOS7 support is dropped so it's a minor transition (as I<br>
believe the target is Train for full python3 support).<br>
<br>
The second method is to add in a new configuration option that allows<br>
for package names to be overrideable/replaced. See<br>
<br>
<a href="https://review.openstack.org/#/c/636403/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/636403/</a> (kolla package-replace option)<br>
<a href="https://review.openstack.org/#/c/636457/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/636457/</a> (kolla python3 specifics)<br>
<a href="https://review.openstack.org/#/c/624838/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/624838/</a> (kolla WIP for fedora support<br>
would need to be supplied to test)<br>
<a href="https://review.openstack.org/#/c/636472/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/636472/</a> (tripleo specific overrides)<br>
<br>
IMHO I actually like the package-replace option for a few package<br>
overrides.  I don't think this is a cleaner implementation for<br>
replacing all the packages because it becomes less obvious what<br>
packages would actually be used and it becomes more complex to manage.<br>
This one feels more like it's pushing the complexity to the end user<br>
and would still be problematic when CentOS8 comes out all the packages<br>
would still need to be replaced in all the Docker files (in the next<br>
cycle?).<br>
<br>
My personal preference would be to proceed with the first method and<br>
maybe merge the package-replace functionality if other would find it<br>
beneficial.  I would be interested to hear if other think that the<br>
second option would be better in the long term.<br>
<br>
Thanks,<br>
-Alex<br></blockquote><div><span class="gmail_default" style="font-family:verdana,sans-serif">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.</span> <span class="gmail_default" style="font-family:verdana,sans-serif"> My vote is for the first option.</span></div><div><span class="gmail_default" style="font-family:verdana,sans-serif">Mark</span></div></div></div>