On Tue, Jan 5, 2021 at 12:53 AM Cédric Jeanneret <cjeanner@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. Thanks, -Alex
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/