Bug 1686359

Summary:	[gluster-ansible] Fail at the very beginning, when pre-requisites for RHHI-V deployment is not met
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	SATHEESARAN <sasundar>
Component:	gluster-ansible	Assignee:	Sachidananda Urs <surs>
Status:	CLOSED ERRATA	QA Contact:	SATHEESARAN <sasundar>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	rhgs-3.4	CC:	bugs, godas, myllynen, rhinduja, rhs-bugs, sabose, sasundar
Target Milestone:	---	Keywords:	ZStream
Target Release:	RHGS 3.4.z Async Update
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	gluster-ansible-roles-1.0.5-2, gluster-ansible-features-1.0.5-2	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1686357	Environment:
Last Closed:	2019-10-03 07:58:12 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Gluster	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1686357

Description SATHEESARAN 2019-03-07 10:24:09 UTC

Description of problem:
-----------------------
gluster-ansible roles executes even after the error is encountered.
For example, 512b validation has failed on the disk and ansible task of creating thinpool, lv, creating XFS, just continues even though it identified that the disk is not suitable for RHHI deployment

Version-Release number of selected component (if applicable):
--------------------------------------------------------------
cockpit-ovirt-dashboard-0.12.4

How reproducible:
------------------
Always

Steps to Reproduce:
-------------------
1. Provide a non 512b logical-sized brick for RHHI deployment

Actual results:
---------------
thinpool creation, lv creation, and XFS creation happens on the disk, eventhoughh the flow identifies that the disk is not suitable for RHHI deployment

Expected results:
-----------------
Ansible flow should abort further tasks execution once it finds out an error in the deployment

--- Additional comment from SATHEESARAN on 2019-03-07 10:22:40 UTC ---

Ansible has this option to abort the execution on failure. Thanks Sac for letting us know about it.
https://docs.ansible.com/ansible/latest/user_guide/playbooks_error_handling.html#aborting-the-play

'any_errors_fatal: true' aborts the execution of any other tasks, once the error is encountered.

Comment 1 SATHEESARAN 2019-03-28 07:21:30 UTC

The discussion keep happening in the dependent bug, the last comment is to test with max_fail_percentage to 1 and any_errors_fatal: true

Comment 2 Gobinda Das 2019-05-09 04:21:30 UTC

@sas Have you got chance to test with max_fail_percentage: 1 ?

Comment 3 SATHEESARAN 2019-05-15 06:38:36 UTC

(In reply to Gobinda Das from comment #2)
> @sas Have you got chance to test with max_fail_percentage: 1 ?

Looks like all these prechecks are defined as part of ansible pretasks.
This change will be in gluster-ansible component of RHGS. I will move this bug accordingly

Comment 5 Sachidananda Urs 2019-05-15 08:26:17 UTC

https://github.com/gluster/gluster-ansible/pull/70
https://github.com/gluster/gluster-ansible-features/pull/27

Comment 6 SATHEESARAN 2019-06-01 02:19:23 UTC

Test case for this bug will involve:
1. Make sure all the pre-check fails much ahead before real deployment
rather than attempting for deployment and then failing during deployment

Comment 8 SATHEESARAN 2019-06-26 06:03:45 UTC

Tested with RHVH 4.3.5 + RHEL 7.7 + RHGS 3.4.4 ( interim build - glusterfs-6.0-6 ) with ansible 2.8.1-1
with:
gluster-ansible-features-1.0.5-2.el7rhgs.noarch
gluster-ansible-roles-1.0.5-2.el7rhgs.noarch
gluster-ansible-infra-1.0.4-3.el7rhgs.noarch

Pre-flight tests are now moved in ansible pre-tasks

Comment 11 errata-xmlrpc 2019-10-03 07:58:12 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/RHBA-2019:2557