Bug 1532083

Summary:	[RFE][DR] - Add validation task for var file in a disaster recovery scenario
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Maor <mlipchuk>
Component:	ovirt-ansible-roles	Assignee:	Maor <mlipchuk>
Status:	CLOSED ERRATA	QA Contact:	Elad <ebenahar>
Severity:	medium	Docs Contact:
Priority:	high
Version:	unspecified	CC:	bburmest, dfodor, lsvaty, ratamir, tnisan, ylavi
Target Milestone:	ovirt-4.2.3	Keywords:	FutureFeature, Improvement
Target Release:	---	Flags:	ebenahar: ci_coverage_complete? ebenahar: testing_plan_complete+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	DR
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	Added a new script to execute several operations, such as validate, fail-over, fail-back, generate_vars	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-05-15 18:00:47 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-08 00:01:49 UTC

Description of problem:

There should be a utility to validate the mapping input before the user will run the recovery process to prevent any failures on recovery.

The user should run this utility after it generates the var file and set all the destination info.

The utility will check the existence of affinity groups/labels, aaa domains, clusters names, active hosts on each of the data centers, and other properties which are legit to be tested.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Generate var file automatically using ovirt-ansible-disaster-recovery
2. Set all the destination info of all the storage domains and other mapping
3. Validate whether all the data entered by the user is valid and exists on the destination setup

Actual results:


Expected results:


Additional info:

Comment 3 Maor 2018-05-02 14:44:19 UTC

The validation script is already in.
Users can use it to validate their mapping var file.

Comment 4 Elad 2018-05-07 13:58:17 UTC

Mapping var file validation is now possible:

[ebenahar@dhcp-4-209 files]$ sudo ./validator.py /var/lib/ovirt-ansible-disaster-recovery/mapping_vars.yml
[sudo] password for ebenahar: 
[Validate Mapping File] Validate variable mapping file for oVirt ansible disaster recovery
[Validate Mapping File] Var File: '/var/lib/ovirt-ansible-disaster-recovery/mapping_vars.yml'
[Validate Mapping File] Please provide vault password for file '/usr/share/ansible/roles/oVirt.disaster-recovery/ovirt_passwords.yml' (For plain file, please press enter): 1
[Validate Mapping File] mapping dr_affinity_group_mappings is empty in var file
[Validate Mapping File] mapping dr_affinity_label_mappings is empty in var file
[Validate Mapping File] Can not read passwords from vault. Will try to read as plain file.
[Validate Mapping File] Finished validation for 'dr_network_mappings' for primary setup with success.
[Validate Mapping File] Finished validation for 'dr_cluster_mappings' for key name 'primary_name' with success.
[Validate Mapping File] Finished validation for 'dr_network_mappings' for secondary setup with success.
[Validate Mapping File] Finished validation for 'dr_cluster_mappings' for key name 'secondary_name' with success.
[Validate Mapping File] Finished validation variable mapping file for oVirt ansible disaster recovery


For example, in this validation dr_affinity_group_mappings and dr_affinity_label_mappings are reported to be empty with a warning.


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

Comment 7 errata-xmlrpc 2018-05-15 18:00:47 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:1534

Comment 8 Franta Kust 2019-05-16 13:04:34 UTC

BZ<2>Jira Resync