Description of problem: The fix for bug 1492138 is not enough. Currently, if failure is after adding SchemaTransaction, abort clears the database. Need to check what's the best solution. Definitely, if we do not backup, and it's not a new database, we should not clear.
QE: Reproduction/verification flows: 1. Install and Setup 4.1 engine+dwh, also install otopi-debug-plugins if you want (see below) 2. Update setup packages to 4.2 3. Run engine-setup and fail it. Please test with different fail points. You can automate this using the force_fail plugin of otopi-debug-plugins using one of these (please try all, please automate for the future): OTOPI_FORCE_FAIL_STAGE=STAGE_EARLY_MISC OTOPI_FORCE_FAIL_PRIORITY=PRIORITY_LOW engine-setup OTOPI_FORCE_FAIL_STAGE=STAGE_MISC OTOPI_FORCE_FAIL_PRIORITY=PRIORITY_HIGH engine-setup OTOPI_FORCE_FAIL_STAGE=STAGE_MISC OTOPI_FORCE_FAIL_PRIORITY=PRIORITY_DEFAULT engine-setup OTOPI_FORCE_FAIL_STAGE=STAGE_MISC OTOPI_FORCE_FAIL_PRIORITY=PRIORITY_LOW engine-setup 4. engine-setup, also if rolling back successfully, leaves all services stopped. So: systemctl start ovirt-engine systemctl start ovirt-engine-dwhd 5. Verify that both services eventually managed to come up and work well. You can try to login, check logs etc.
Patch was merged after tagging the latest build, will have to wait for next one.
I ran stage fails from 3. in Comment 1. Databases are not empty after rollback and services work ok. verified in ovirt-engine-setup-4.2.2.2-0.1.el7.noarch
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 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.