Bug 1403937

Summary:	The restore command requires the engine service to be down but doesn't disable it and so it could badly fail if for any reason the system reboots
Product:	[oVirt] ovirt-engine	Reporter:	Simone Tiraboschi <stirabos>
Component:	Backup-Restore.Engine	Assignee:	Nobody <nobody>
Status:	CLOSED DEFERRED	QA Contact:	Lukas Svaty <lsvaty>
Severity:	low	Docs Contact:
Priority:	medium
Version:	4.0.4.2	CC:	bugs, michal.skrivanek, sbonazzo
Target Milestone:	---	Keywords:	EasyFix
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-04-01 14:33:05 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:

Description Simone Tiraboschi 2016-12-12 16:30:27 UTC

Description of problem:
engine-backup --mode=restore imports the engine DB and the required configuration files but it still requires a run of engine-setup to properly align the engine DB to installed version.
So, it enforces the engine service to be down and it asks the user to manually run engine-setup at the end.

If for any reason (for instance because the engine is on a VM and the user forgot to set global maintenance mode: within a few minutes ovirt-ha-agent is going to reboot the engine VM) the system reboots before the user could run engine-setup, the engine service is not disabled and so it restart with a possibly incompatible database resulting in obscure errors.

Ensuring that the engine-service is explicitly disabled and not just stopped will prevent this; enabling again the engine service will be up to engine-setup.

Version-Release number of selected component (if applicable):

How reproducible:
The issue is systematic, the symptoms (possibly none) are instead related to the differences between the system where the backup got generated with the system where it got restored.

Steps to Reproduce:
1. restore an engine backup
2. reboot the system before running engine-setup
3. after the reboot check the status of the engine

Actual results:
the engine was just stopped but not disabled so after a reboot it will restart also if the DB has still to be upgraded

Expected results:
the engine will not restart till the user runs engine-setup again

Additional info:
The user has a valid engine backup so he could simply try again the restore procedure.

Comment 1 Yaniv Lavi 2018-06-25 07:32:17 UTC

Closing old bugs.
Please reopen if still relevant.
Patches are welcomed.

Comment 2 Yedidyah Bar David 2018-06-25 07:45:38 UTC

I think it can be important, reopening. Should be a quite easy fix - disable engine service during restore. engine-setup should enable it (and we should verify that).

Comment 4 Michal Skrivanek 2020-03-19 15:05:34 UTC

simple, yet it's not fixed for 2 years. on track for 4.4.1? or no capacity?

Comment 5 Michal Skrivanek 2020-03-19 15:41:58 UTC

We didn't get to this bug for more than 2 years, and it's not being considered for the upcoming 4.4. It's unlikely that it will ever be addressed so I'm suggesting to close it.
If you feel this needs to be addressed and want to work on it please remove cond nack and target accordingly.

Comment 6 Michal Skrivanek 2020-04-01 14:33:05 UTC

ok, closing. Please reopen if still relevant/you want to work on it.

Comment 7 Sandro Bonazzola 2020-04-02 13:17:15 UTC

(In reply to Michal Skrivanek from comment #4)
> simple, yet it's not fixed for 2 years. on track for 4.4.1? or no capacity?

low severity, we always had more urgent stuff to fix. Ok for closing deferred.