Description of problem: otopi's systemd services plugin has hardcoded '.service' suffix for services. This make it impossible to use it to start/stop/enable/disable systemd socket units. See also bug 1704282 for a concrete case - cockpit now has a socket unit, and enabling the cockpit service is not enough, need to enable also the socket unit.
*** Bug 1721070 has been marked as a duplicate of this bug. ***
QE: It's a bit hard to verify current bug without bug 1704282. We currently decided to "fix" current bug treating it as an RFE - adding a new function to otopi's API, which plugins can use - startupSocket. So no existing code should change its behavior due to upgrading to a fixed version. In bug 1704282, we change ovirt-host-deploy to use this new function. The reason we didn't "fix" but instead added a feature is that at least in the mentioned case, of 'cockpit', it has both a systemd service unit and a socket unit. So when otopi is asked to enable cockpit, it should not guess which one should be enabled, it should be up to host-deploy to decide. I now pushed to otopi a patch that adds a debug plugin for otopi services stuff, which also allows enabling/disabling a socket unit: https://gerrit.ovirt.org/101791 Once it's ready, it can be used for verification directly (without host-deploy). Otherwise, verifying bug 1704282 should be enough to consider current bug verified as well.
So you can re-target this to 4.3.6 and then Petr will verify them together?
Done. Please note that the actual code will be shipped in 4.3.5, but as I wrote, it should not affect any existing code, so should be safe.
As bug 1704282 is targeted to 4.5 maybe this should be also retargeted. Or we can verify it with sanity only as it didn't break anything yet.
Sanity is enough. Bug 1704282 is irrelevant anymore, as the fix for it will not be in ovirt-host-deploy (removed in 4.4) but in ansible code.
Verified on otopi-common-1.9.0-1.el8ev.noarch
This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.