[rdo-list] Using rh-python35 Software Collection to package python service

Tristan Cacqueray tdecacqu at redhat.com
Fri Jul 14 03:54:31 UTC 2017


Hello folks,

If I understood correctly, SCL (Software Collection) is the main Red Hat
supported solution to have py3 on el7 and el8, so I gave the rh-python35
collection a try to package the zuulv3 services. Here is how it went:

First I added scl-utils-build, rh-python35-build and rh-python35-runtime
to the koji target build groups so that a single buildroot could be used
for scl and non scl packages.

Then I wrote a pip2spec[0] script to render spec file for the 52 missing
dependencies[1]. It collects the sdist url, licence and the last version
of the pip requirements.txt, to render a valid scl spec file. I couldn't
use fedora specs or openstack renderspec because scl is quite intrusive:
* The spec defines only one package, regardless of the python runtime
* The %build, %install and %check section needs to be wrapped using
  %{?scl:scl enable %{scl} - << \EOF}
  ...
  %{?scl:EOF}

Lastly for the zuul package[2], this got a bit more tricky:
* The buildroot path are all offsetted with the scl prefix, the confmgmt
  needed to be adapted to use the new paths:
  /etc/opt/rh/rh-python35/zuul
  /etc/opt/rh/rh-python35/sysconfig/zuul
  /var/opt/rh/rh-python35/lib/zuul
  /var/opt/rh/rh-python35/log/zuul

* The systemd service files also needed to be modified. I first tried to
  use the scl command wrapper as documented in the guide, but this spawn
  the service in a subprocess which breaks service reload (the SIGHUP is
  not sent to the right process). Though a new sysconfig EnvironmentFile
  is actually easier to activate the scl:
  PATH=/opt/rh/rh-python35/root/usr/bin:/bin
  LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64

* Finaly, the custom LD_LIBRARY_PATH is a blocker when the service calls
  a setuid program. The zuul executor uses bubblewrap to contain Ansible
  execution, and this failed with:
  error while loading shared libraries: libpython3.5m.so.rh-python35-1.0
  cannot open shared object file: No such file or directory
  To fix that, I had to create symlink for the libpython3.5m.so* and the
  python3.5 directory to /lib64/, which is not ideal because the scl now
  affects system wide packages.

TL,DR:
Using SCL is quite an intrusive change, and unless we somehow remove the
scl path prefix, confmgmt needs to be modified to properly configure the
services. Moreover, the rh-python35 comes with a limited set of packages
and many dependencies will need to be packaged too.

Another alternative would be to package a system wide python3 runtime so
that we could keep the fedora spec compatibility, but that sounds like a
difficult path too.

Either way, we will likely lose all the packages that come for free with
the default centos python runtime. Though it may be possible to automate
most of the work to keep them in sync with the upper-constraints...

Best regards,
-Tristan

[0]: https://softwarefactory-project.io/paste/show/822/
[1]: https://softwarefactory-project.io/r/gitweb?p=config.git;a=blob_plain;f=resources/scl.yaml;hb=HEAD
[2]: https://softwarefactory-project.io/r/gitweb?p=scl/zuul-distgit.git;a=tree
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20170714/c3de5c0c/attachment.sig>


More information about the dev mailing list