Description of problem: In 3.2, the notifier daemon is called engine-notifierd while on 3.3 it's ovirt-engine-notifier. On upgrade from 3.2 to 3.3, notifications are lost with the upgrade, because the ovirt-engine-notifier is not running after the upgrade. Expected results: Start anch chkconfig on ovirt-engine-notifier if engine-notifierd is running and set to start automatically.
*** Bug 1083649 has been marked as a duplicate of this bug. ***
This is nasty... as we did not want to modify this service startup automatically. And after upgrade we no longer have the old service so we cannot query it. So probably we need to do this at spec %pre/%post? or look into dead link at /etc/rc.d?
In 3.2 -> 3.3 there is also a package refactoring: notification-service subpackage is now provided in 3.3 by tools subpackage. Since this update is done under version locking, I think we can get the service status before shutting it down and then restore it on the new service after update. We already try to do that in hostile_service plugin without taking care of the name change.
Alon, it looks like otopi we can only set startup and not query it. Can you add an "enabled" method returning True if the service is enabled?
(In reply to Sandro Bonazzola from comment #4) > Alon, it looks like otopi we can only set startup and not query it. > Can you add an "enabled" method returning True if the service is enabled? I already discussed this with Alon in some other context, and it's not trivial. What if the service is enabled, but not with its defaults? E.g. suppose some service that is by default enabled at runlevels 2-5 at "stage" 90 (is that the term?), and on a specific machine it's enabled only at levels 3 and 4 at stage 95. If you disable, then decide to enable again, you have to: 1. Decide if you want the default or keep old state 2. Somehow save old state so that you can restore it 3. Do the above for all supported init systems
So just add a note about "During the upgrade engine-notifierd service has been renamed to ovirt-engine-notifier. The new service is not enabled by default. You can re-enable it by using {command}" with command depending on init system? Whoever changed defaults settings for the previous service is able to do the same here.
I agree with your comment 3. If it's up, we'll enable it. Worst case it was manually started and not enabled on boot, and now will start on boot. Perhaps we should add a note about that.
(In reply to Sandro Bonazzola from comment #4) > Alon, it looks like otopi we can only set startup and not query it. > Can you add an "enabled" method returning True if the service is enabled? I did not do this as it was too difficult to know if service is enabled during boot, what run level to check, what boot profile, etc... If all is done under versionlock then checking if running before is good enough.
Since in 3.4 we use the same name of the service as in 3.3, this bug doesn't affect it, so no change is needed on 3.4.
Moving back to assigned. On 3.4 daemon are started but not enabled for surviving reboot.
Behavior before the fix, 3.4+: If ovirt-engine-notifier was up, and then: * engine-cleanup was ran - it stopped it, then tried to start it (which failed while trying to connect to the db) * engine-setup was ran - it stopped it, and did not try to start it in the end Behavior with the fix, 3.4+: Opposite of before - cleanup does not try to start it in the end, other actions (setup, rename) do, and they also enable it to start on boot.
bad script, reverting.
in rhevm-setup-3.5.0-0.10.master.el6ev.noarch
Not sure this requires doc text. See comment 13 for the actual change.