Description of problem: This is a duplicate of bug 1024028. In it, it was requested that if engine-setup sets up dwh against some engine DB, and notices that another dwh is already running against this engine, it would stop it. This used to work fine, but at some point was broken. Also, at the time, it only worked on the engine machine, because the code implementing this was part of an engine package - and later it was moved to dwh-setup, but the condition that it's only working on the engine machine was left in. I already pushed two patches that fix above issues, when I worked on bug 1877279: https://gerrit.ovirt.org/111200 https://gerrit.ovirt.org/111201 They are simple patches and work. However, it's not completely clear to me that we actually want the behavior requested in bug 1024028. Why? Consider the following flow. It's a bit complex, but I think it nicely demonstrates the issue - which applies also with somewhat simpler flows: 1. Install and setup engine on machine A 2. Install and setup dwh on machine B, against the engine db in A. This asks to stop and disable dwh on A, and you do. 3. Install and setup dwh on machine C, with current bug fixed, against the engine in A. Since the bug is fixed, you are not requested to stop and disable dwh on B - engine-setup, instead, asks dwh to stop, and dwh on B notices and stops, and then engine-setup on C continues happily. 4. Reboot B. Since dwh is still enabled there, it will start. This should not be a real problem, because it should notice that another dwh (on C) is up (or at least configured), so it will log an error and exit. But this is a bit confusing for the user. So perhaps it's better to just give up on bug 1024028, and just always ask the user to stop and disable. We can't (easily) disable dwh on B (in above flow). I tend to vote 'Yes', do merge above patches and fix current bug, mainly for convenience for the user. I think we should still prompt the user asking to stop and disable, but also stop it automatically if the user didn't. At the time, I also pushed a patch adding technical documentation for this feature: https://gerrit.ovirt.org/111178 It's not merged yet, and the current text there assumes that current bug is not fixed - see lines 29-32 there, and also no mention of automatic stop in lines 40-43, as opposed to in lines 45-47.
Following an internal discussion, we are going to merge the patches, and I'll review the prompt text.
This bug has a low overall severity and passed automated regreession suite, it is not going to be further verified by QE. If you believe a special care is required feel free to re-open to ON_QA status
This bugzilla is included in oVirt 4.4.4 release, published on December 21st 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.4 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.