Bug 1723933

Summary:	systemd services plugin does not support socket units
Product:	[oVirt] otopi	Reporter:	Yedidyah Bar David <didi>
Component:	Plugins.services	Assignee:	Yedidyah Bar David <didi>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Petr Matyáš <pmatyas>
Severity:	medium	Docs Contact:
Priority:	high
Version:	master	CC:	bugs, eslutsky, lleistne
Target Milestone:	ovirt-4.4.0	Keywords:	ZStream
Target Release:	1.8.3	Flags:	sbonazzo: ovirt-4.4?
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	otopi-1.8.3	Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-05-20 20:02:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Integration	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1723938

Description Yedidyah Bar David 2019-06-25 19:20:36 UTC

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.

Comment 1 Evgeny Slutsky 2019-06-30 08:06:18 UTC

*** Bug 1721070 has been marked as a duplicate of this bug. ***

Comment 2 Yedidyah Bar David 2019-07-14 06:25:14 UTC

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.

Comment 3 Lucie Leistnerova 2019-07-15 08:35:15 UTC

So you can re-target this to 4.3.6 and then Petr will verify them together?

Comment 4 Yedidyah Bar David 2019-07-16 07:33:00 UTC

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.

Comment 5 Petr Matyáš 2020-03-20 11:36:21 UTC

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.

Comment 6 Yedidyah Bar David 2020-03-22 08:47:03 UTC

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.

Comment 7 Petr Matyáš 2020-03-23 12:52:51 UTC

Verified on otopi-common-1.9.0-1.el8ev.noarch

Comment 8 Sandro Bonazzola 2020-05-20 20:02:57 UTC

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.