Bug 1532083 - [RFE][DR] - Add validation task for var file in a disaster recovery scenario
Summary: [RFE][DR] - Add validation task for var file in a disaster recovery scenario
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-ansible-roles
Version: unspecified
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ovirt-4.2.3
: ---
Assignee: Maor
QA Contact: Elad
URL:
Whiteboard: DR
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-08 00:01 UTC by Maor
Modified: 2019-05-16 13:04 UTC (History)
6 users (show)

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
Clone Of:
Environment:
Last Closed: 2018-05-15 18:00:47 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:
ebenahar: ci_coverage_complete?
ebenahar: testing_plan_complete+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github oVirt ovirt-ansible-disaster-recovery pull 38 0 None None None 2018-03-15 11:58:32 UTC
Red Hat Product Errata RHEA-2018:1534 0 None None None 2018-05-15 18:01:13 UTC

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


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