Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1533385

Summary:	[DR] - Fail back clean the entire setup instead of cleaning only the storage domains mapped in the mapping var file
Product:	[oVirt] ovirt-ansible-collection	Reporter:	Maor <mlipchuk>
Component:	disaster-recovery	Assignee:	Maor <mlipchuk>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Elad <ebenahar>
Severity:	medium	Docs Contact:
Priority:	high
Version:	unspecified	CC:	amureini, ebenahar, lsvaty, mlipchuk, ylavi
Target Milestone:	ovirt-4.2.2	Flags:	rule-engine: ovirt-4.2+ ylavi: blocker+
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	DR
Fixed In Version:	ovirt-ansible-disaster-recovery-0.2	Doc Type:	Bug Fix
Doc Text:	Cause: Failback is applied on the entire setup and clean all the storage domains Consequence: fail back will clean the entire setup, even storage domains which are not mapped in the var file Fix: clean up should be done only on mapped storage domains Result: Failback will remove the mapped active storage domains. Additional fix should be performed on storage domains in maintenance.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-05-10 06:23:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Maor 2018-01-11 08:53:43 UTC

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):


How reproducible:


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
2.
3.

Actual results:
All storage domains will be detached

Expected results:
The process should go over all the mapped storage domains, detach and remove  them.

Additional info:
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

Comment 1 Allon Mureinik 2018-02-08 10:30:15 UTC

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?

Comment 2 Maor 2018-02-08 14:19:04 UTC

(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

Comment 3 Allon Mureinik 2018-02-27 14:19:38 UTC

Maor, please update the target release too.

Comment 4 Maor 2018-03-01 13:27:37 UTC

(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.

Comment 5 Elad 2018-05-09 17:50:19 UTC

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


Used:
ovirt-ansible-disaster-recovery-0.4-1.el7ev.noarch
ansible-2.5.2-1.el7ae.noarch

Comment 6 Sandro Bonazzola 2018-05-10 06:23:10 UTC

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.