[tripleo] Package dependencies, podman, dnf modules

Alex Schultz aschultz at redhat.com
Tue Jan 5 14:57:19 UTC 2021

On Tue, Jan 5, 2021 at 12:53 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.
> 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.

So as mentioned we did this and it leads to poor UX because the
conflict message doesn't help direct people to fixing their
container-tools module.

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

IMHO This really needs to be in the RPM spec ASAP to make modules
viable in the long term but that's not an OpenStack issue.

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

Since we may or may not consume podman in code we're packaging we
likely should not drop the requirement.

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

IMHO, as mentioned on IRC, we need to improve the initial setup
process to reduce the likelihood of a misconfiguration.  I had chatted
with the CI folks on the best way to solve this in a single place that
would be useful for users and in CI. We generally agreed to combine
the efforts into tripleo-repos because it can be installed
independently of everything else and can be a single source of truth
for version info.  I proposed a WIP for a version information
structure so we can have a single source of truth for repo and version
information. https://review.opendev.org/c/openstack/tripleo-repos/+/767214
Today we require the user to manually setup repositories and module
versions prior to installing the packages.  I think it's best if we
work on reducing the errors that occur during this process.  We could
add something into the validation bits, but we will still need a
single source of truth for the required versions so we're not
duplicating the version information.


> 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/

More information about the openstack-discuss mailing list