Description of problem: It might happen operator doesn't have the right repositories enabled, and it might lead to a wrong version of podman being pulled in. This is shown for instance here: https://bugzilla.redhat.com/show_bug.cgi?id=1860640 An idea would be to set that upper limit against paunch package, since it's installed everywhere (for now). The version should prevent to install any other version than podman-1.6.4* Cheers, C.
Seems something has been corrected in the meantime, but having this security net wouldn't hurt: https://bugzilla.redhat.com/show_bug.cgi?id=1858373
Upstream proposal: https://review.rdoproject.org/r/#/c/28853/ We probably want the same downstream.
I think we want a minor version limit as well. Updates to 16.1 are getting set up with the wrong module streams, causing a podman version that's too old to get picked up (and with which new instances can't spawn). https://bugzilla.redhat.com/show_bug.cgi?id=1866290 https://bugzilla.redhat.com/show_bug.cgi?id=1866479 We need podman-1.6.4-15 or higher.
Without turning things into modules, there's no simple way to hard-require modular content. Cedric and I had a proposal to fail the RPM transaction without the proper module stream being present, but it was rejected. If we wanted, we could build a modular build of something - say, python-tripleoclient - with nothing in it but python3-tripleoclient. That module could depend on specific module streams we need. This would fail the transaction if the incorrect module streams were enabled. However, it will not obviate any steps for the customer; they will still have to manually enable the correct modular streams as defined in our documentation. There are other possibilities in flight at the moment, such as providing metadata that can be utilized via the validations framework.
*** This bug has been marked as a duplicate of bug 1878187 ***