Open Stack

Hello everyone,

I am hoping for some feedback from our developers/users on a potential
solution to a python 2/3 compatibility issue we are hitting in dib:

We ran in to a couple issues adding Fedora 23 support to
diskimage-builder caused by python2 not being installed by default.
This can be solved pretty easily by installing python2, but given that
this is eventually where all our supported distros will end up I would
like to find a better long term solution (one that allows us to make
images which have the same python installed that the distro ships by
default).

The problem is that many elements provide python scripts (such as
package-installs-v2 in the package-installs element) which we exec
during the image build process. We use +x and a #! to specify a python
interpreter, but this needs to be python3 on distros which do not ship a
python2, and python elsewhere. There is also one script
(pacakge-installs-squash) which runs outside of the chroot, but
otherwise all python scripts run inside the chroot.


Some brainstorming was done in #tripleo, and we came up with the
following plan for fixing this:

Create a symlink in the chroot from /usr/local/bin/dib-python to
whatever the apropriate python executable is for that distro. We will
then use dib-python in our #! lines for scripts which run in the chroot.

Scripts outside of the chroot will have to perform their own python
version detection and call any python using the detected python
interpreter - this is only one package-installs-squash script so
this seemed like not a big issue.


The other solutions we considered:

Switching everything to depend on python3 - This is ruled out since
rhel7/centos7 do not ship a python3 package.

Automatically rewriting #! lines as we exec them - This could work. I
personally think the sylink is simpler and solves the problem equally as
well.


Thoughts?

Cheers,
Greg