Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1532083 - [RFE][DR] - Add validation task for var file in a disaster recovery scenario
[RFE][DR] - Add validation task for var file in a disaster recovery scenario
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-ansible-roles (Show other bugs)
unspecified
Unspecified Unspecified
high Severity medium
: ovirt-4.2.3
: ---
Assigned To: Maor
Elad
DR
: FutureFeature, Improvement
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2018-01-07 19:01 EST by Maor
Modified: 2018-08-28 07:45 EDT (History)
6 users (show)

See Also:
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 14:00:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ebenahar: ci_coverage_complete?
ebenahar: testing_plan_complete+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Github oVirt/ovirt-ansible-disaster-recovery/pull/38 None None None 2018-03-15 07:58 EDT
Red Hat Product Errata RHEA-2018:1534 None None None 2018-05-15 14:01 EDT

  None (edit)
Description Maor 2018-01-07 19:01:49 EST
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 10:44:19 EDT
The validation script is already in.
Users can use it to validate their mapping var file.
Comment 4 Elad 2018-05-07 09:58:17 EDT
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 14:00:47 EDT
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

Note You need to log in before you can comment on or make changes to this bug.