On 1/5/21 12:45 PM, Bogdan Dobrelya wrote:
On 1/5/21 12:02 PM, Cédric Jeanneret wrote:
On 1/5/21 11:48 AM, Cédric Jeanneret wrote:
On 1/5/21 9:56 AM, Marios Andreou wrote:
On Tue, Jan 5, 2021 at 9:44 AM Cédric Jeanneret <cjeanner@redhat.com mailto: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.
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 here.
Right - always hard to find the right starting point ;). Though a mail would be a nice thing in order to get directions/ideas - and, hey, you just pointed some already! Here's the LP: https://bugs.launchpad.net/tripleo/+bug/1910217
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.
Good catch. Maybe by ordering a bit things and calling the podman install bit before calling the heat-launcher? Might be ugly and, well, against some of the common practices, but at least it would ensure we get what we actually want regarding versions and sources.
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 ?
exactly. Ansible is able to switch module streams, and install packages. Basically, we'd "just" need to extend a bit this role/task: https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansi...
That would make things cleaner, nicer, and more reliable.
Maybe we can keep the dependency as-is, and "just" ensure tripleo-ansible "tripleo_podman" role sets the right things during the deploy time? For instance, we can add a task ensuring we're using the right stream, then install podman (and buildah). That means heat-launcher might use the wrong podman version (bleh...) but the finished undercloud should be fine? Not 100% sure it's really possible, especially since module switching might fail under some conditions when a package is installed :/.
I propose to use in RPM specs
Requires: podman Conflicts: podman < some_lower_constraint_version
that would allow to fail early if, a wrong version is going to be installed via existing repos and streams. And failing early is much better than waiting up to the moment it starts running ansible IMHO. And at that later point it would only re-ensure the wanted version.
We'll need to set an upper constraint - in some conditions, the default version is newer than the one we actually want. This is already done, more or less, downstream with an OSP specific package. While it sounds appealing, I still see issues when it comes to version changes. I'd rather ensure we have the proper stream activated, especially since your proposal will lead to more LP/BZ being opened by ppl that don't read the doc© - resulting in endless bounces and more complains about the non-user-friendliness of this approach :(.
Ah, also.... we seem to have the same kind of constrain with some "virt" module - default is "rhel" but we apparently need another one (iirc "8") - though this seems to be downstream-only, and only for the overcloud (or standalone)... So the issue isn't "just" for podman, and a better, generic thing would be really nice :).
Cheers,
C.
Guess some testing will be needed as well.
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?
AFAIK, module support within RPM spec file as a standard thing is not in the roadmap. Apparently, the ppl behind this "module" concept aren't willing to add any sort of support. I've worked with Lon (Red Hat side) for the patch in the spec file, we've tried multiple ways and, well...... it's really not something I'm happy with. One idea I just got was about rpm hooks - iirc there's a thing in dnf that might help, have to read some more things about that. But I have the feeling this is still the wrong way - unless it's considered as a "last security net just to be really-really sure", instead of the current usage we have (which is, basically, ensure ppl do read the doc and follow it).
So the main thing: it's not a TripleO issue per se - we're just using a feature that has a weak support in some cases, and, well, we happen to hit one of those cases. As usuall I'd say ;).
Cheers,
C.
thanks, marios
Thank you for your thoughts!
Cheers,
C.
[1] https://review.rdoproject.org/r/#/c/31411/ 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/ https://www.redhat.com/