Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1083551 - notifier daemon is not keeping startup settings after upgrade to 3.3
Summary: notifier daemon is not keeping startup settings after upgrade to 3.3
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-setup
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
: 3.5.0
Assignee: Yedidyah Bar David
QA Contact: Pavel Stehlik
URL:
Whiteboard: integration
: 1083649 (view as bug list)
Depends On: 1103084
Blocks: 1083649 1103044 1110307 rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2014-04-02 12:55 UTC by Petr Beňas
Modified: 2015-02-12 14:16 UTC (History)
16 users (show)

Fixed In Version: ovirt-engine-3.5.0_beta
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1083649 1103044 1110307 (view as bug list)
Environment:
Last Closed: 2015-02-12 14:16:14 UTC
oVirt Team: ---
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 28235 master MERGED packaging: setup: ensure restarted services survive reboot Never
oVirt gerrit 28880 ovirt-engine-3.4 MERGED packaging: setup: ensure restarted services survive reboot Never

Description Petr Beňas 2014-04-02 12:55:36 UTC
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.

Comment 1 Sandro Bonazzola 2014-04-07 07:46:08 UTC
*** Bug 1083649 has been marked as a duplicate of this bug. ***

Comment 2 Alon Bar-Lev 2014-04-07 07:55:20 UTC
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?

Comment 3 Sandro Bonazzola 2014-04-08 09:52:29 UTC
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.

Comment 4 Sandro Bonazzola 2014-04-08 10:11:30 UTC
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?

Comment 5 Yedidyah Bar David 2014-04-08 10:18:10 UTC
(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

Comment 6 Sandro Bonazzola 2014-04-08 10:27:21 UTC
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.

Comment 7 Yedidyah Bar David 2014-04-08 10:36:45 UTC
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.

Comment 8 Alon Bar-Lev 2014-04-08 10:44:49 UTC
(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.

Comment 9 Sandro Bonazzola 2014-05-30 06:49:32 UTC
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.

Comment 11 Sandro Bonazzola 2014-05-30 07:16:56 UTC
Moving back to assigned. On 3.4 daemon are started but not enabled for surviving reboot.

Comment 13 Yedidyah Bar David 2014-06-18 07:48:03 UTC
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.

Comment 14 Eyal Edri 2014-07-22 14:13:17 UTC
bad script, reverting.

Comment 15 Petr Beňas 2014-09-09 10:10:12 UTC
in rhevm-setup-3.5.0-0.10.master.el6ev.noarch

Comment 17 Yedidyah Bar David 2014-11-04 13:19:24 UTC
Not sure this requires doc text. See comment 13 for the actual change.


Note You need to log in before you can comment on or make changes to this bug.