[tripleo] Package dependencies, podman, dnf modules

Marios Andreou marios at redhat.com
Tue Jan 5 08:56:47 UTC 2021

On Tue, Jan 5, 2021 at 9:44 AM Cédric Jeanneret <cjeanner at redhat.com> wrote:

> Hello there,
> 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.

o/ Tengu thanks for socialising that issue, it's a fun one for sure...

first question is _where_ is that the default and it is mostly rhetorical
as I can guess. In general though i think it's worth filing a LP bug with
some of these details so we can also track whatever is decided as a fix

> 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[1], 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

so how does that work in practice though I mean what about
python-tripleoclient. Quick grep just now tells me at least the
heat-launcher is directly using podman. How do we drop that requirement.

> 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).
I am missing how using tripleo-ansible helps us with the stream question.
Do you mean add logic in tripleo-ansible that tests the stream and sets the
correct version ?

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

in general i lean more towards 'ansible tasks' rather than 'bash thing in
the specfile' to solve that. Either way though this is us reacting (with
some fix/hack/workaround) to a problem that isn't anything to do with
TripleO or even OpenStack but rather an OS/packaging issue. So do we have
any longer term plans on what you mentioned on IRC just now regarding
getting module support for RPM deps (do you mean something in the spec file
here?) or is that a complete dead end?

thanks, marios

> Thank you for your thoughts!
> Cheers,
> C.
> [1] https://review.rdoproject.org/r/#/c/31411/
> --
> Cédric Jeanneret (He/Him/His)
> Sr. Software Engineer - OpenStack Platform
> Deployment Framework TC
> Red Hat EMEA
> https://www.redhat.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210105/14372682/attachment.html>

More information about the openstack-discuss mailing list