[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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}

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:

* 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:

* 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.

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,

[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

Attachment: pgpuYKPn7jnul.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]