Description of problem:
We should support cleanup only for a specific storage domains instead of cleaning the entire secondary setup.
This specific clean of a storage domain is necessary for testing purposes.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Call fail back on a setup containing multiple storage domains although only one storage domain is documented in the mapping var file
All storage domains will be detached
The process should go over all the mapped storage domains, detach and remove them.
As part of the fail back scenario we shutdown all VMs for the storage domains to be detached successfully.
In case of only specific storage domain the solution will shutdown all the VMs related to the data center only
Maor, what's going on with this BZ?
It's on POST, but there's no reference to a patch. Is it in the works?
(In reply to Allon Mureinik from comment #1)
> Maor, what's going on with this BZ?
> It's on POST, but there's no reference to a patch. Is it in the works?
Yes, I still work on that, it is published here https://github.com/oVirt/ovirt-ansible-disaster-recovery/tree/BZ1533385
but haven't published as a pull request yet, I will update the PR today and update it also in the bug
Maor, please update the target release too.
(In reply to Allon Mureinik from comment #3)
> Maor, please update the target release too.
Since ovirt-ansible-roles is a metapackage which requires other RPMs the
package isn't bumped.
After advised with Ondra I will update the "Fixed in version" field.
Fail back removes only the mapped storage domains that exist in the var file and not the entire setup.
Please note that for this behavior to take place, all the domains in the target site for fail back have to be in status active.
Domains that are in maintenance for example, will go through cleanup even if they are not written in the var file.
A separate bz for this issue - bug 1576553
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.