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

Mark Goddard mark at stackhpc.com
Mon Feb 18 08:52:56 UTC 2019


On Fri, 15 Feb 2019 at 23:29, Alex Schultz <aschultz at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190218/8ba6c487/attachment.html>


More information about the openstack-discuss mailing list