Description of problem: In oVirt 3.5 the iSCSI LUN used to deploy hosted-engine was added to the engine DB as a fake direct LUN to mark it as used and prevent any misuse that could destroy the whole engine (see https://bugzilla.redhat.com/show_bug.cgi?id=1157238 ). On 3.6 we are able to properly handle the hosted-engine storage domain and so the engine automatically tries to import it. https://gerrit.ovirt.org/#/c/47508/ solves it for new deployment avoid to add it as a fake direct LUN but we have still to handle 3.5 -> 3.6 upgrade for iSCSI deployments. On 3.5 -> 3.6 upgrade the user doesn't need to run hosted-engine-setup and the hosted-engine HA agent doesn't know the admin password to do it vi REST API. So we can fix it: 1. in engine-setup upgrading the engine from 3.5 to 3.6 2. in the engine when the engine tries to auto-import the hosted-engine storage domain. Personally I'm for option 2. Version-Release number of selected component (if applicable): 1.3.0 How reproducible: 100% Steps to Reproduce: 1. deploy hosted-engine from 3.5 on iSCSI 2. upgrade to 3.6 3. Actual results: The hosted-engine LUN is still a fake Direct LUN Expected results: Hosted-engine storage domain appears in the engine Additional info:
*** Bug 1273828 has been marked as a duplicate of this bug. ***
we need to add to the auto import code the removal of the direct lun (if exist). This means to cancel the CanDoAction when removing the hosted engine direct lun disk - RemoveDiskCommand
In oVirt testing is done on single release by default. Therefore I'm removing the 4.0 flag. If you think this bug must be tested in 4.0 as well, please re-add the flag. Please note we might not have testing resources to handle the 4.0 clone.
Is this going to be in this week as well?
*** This bug has been marked as a duplicate of bug 1273378 ***