[tripleo] Package dependencies, podman, dnf modules
cjeanner at redhat.com
Tue Jan 5 07:43:05 UTC 2021
Since we introduced Podman instead of Docker in tripleo, we are running
after the right version.
For now, the version we should use is provided by a specific
container-tools module stream (container-tools:2.0). The default stream
being container-tools:rhel8, we might end with a deployed undercloud
running the wrong podman version, leading to some nice issues,
especially in a SELinux-enabled environment.
Currently, the main dependency tree is:
python3-tripleoclient requires podman
That's mostly all.
While we can, of course, edit the python3-tripleoclient spec file in
order to pin the precise podman version (or, at least, set upper and
lower constraints) in order to target the version provided by the right
stream, it's not ideal:
- package install error will lead to more questions (since ppl might
skip doc for #reason)
- if we change the target version, we'll need to ensure it's present in
a stream (and, well, update the doc if we need to switch the stream)
- and probably some other reasons.
Since we can NOT depend on a specific stream in rpm (for instance, we
can't put "Requires @container-tools:2.0/podman" like we might in
ansible), we're a bit stuck.
An ugly hack is tested in the spec file, using a bash thing in order
to check the activated stream, but this is not ideal either, especially
since it makes the whole package building/checking fail during the
"mock" stage. In order to make it pass, we'd need to modify the whole
RDO in order to take into account stream switching. This isn't
impossible, but it leads to other concerns, especially when it comes to
"hey we need to switch the stream for <module>". And I'm pretty sure no
one will want to dig into it, for good reasons ;).
This leads to a last possibility:
drop the "Requires podman" from tripleo dependency tree, and rely on
tripleo-ansible to actually enable the correct module, and install podman.
This means podman will be installed during the undercloud deploy, for
instance as a host_prep_tasks (step_0).
While I'm not that happy with this idea, it's probably not as bad as the
other hacks we've tested so far, and would, at last, prevent once for
all the usual "it's not working" due to a wrong podman version (and,
yes, we get plenty of them, especially in the OSP version).
What do you think? Any other way of solving this issue? Remember, we're
talking about "ensuring we get the right version, coming from a specific
stream" and, especially, "ensure operator can't install the wrong one"
(if they don't follow the doc, of if they are using automation that
doesn't check actual requirements in the doc"...
Thank you for your thoughts!
Cédric Jeanneret (He/Him/His)
Sr. Software Engineer - OpenStack Platform
Deployment Framework TC
Red Hat EMEA
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 840 bytes
Desc: OpenPGP digital signature
More information about the openstack-discuss