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
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.
(In reply to SATHEESARAN from comment #1) > 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. As I got the information from Gobinda, this variable is already in the play, but still the play doesn't stop on encountering error on one of the host
This issue is not a high severity one, as the playbook ends up in failure, but the concern is that failure is late. So targeting this bug for rhhi-1.7
@sas, can you please try the solution we discussed yesterday? Set, max_fail_percentage to 1 and any_errors_fatal: true
(In reply to Sachidananda Urs from comment #4) > @sas, can you please try the solution we discussed yesterday? > Set, max_fail_percentage to 1 and any_errors_fatal: true The problem statement now looks different, its not about failing early. But check like non-512B disk, /var/log space constraint check should happen at the very beginning and it should fail immediately, when the setup is not eligible for RHHI-V deployment
(In reply to SATHEESARAN from comment #5) > (In reply to Sachidananda Urs from comment #4) > > @sas, can you please try the solution we discussed yesterday? > > Set, max_fail_percentage to 1 and any_errors_fatal: true > > The problem statement now looks different, its not about failing early. But > check like non-512B disk, /var/log space constraint check > should happen at the very beginning and it should fail immediately, when the > setup is not eligible for RHHI-V deployment sas, the pre-requisites are run first before any deployment starts.
Sachi, I did notice the FQDN check was executed after the brick creation. Could the same be true for other validations too?
(In reply to Sahina Bose from comment #7) > Sachi, I did notice the FQDN check was executed after the brick creation. > Could the same be true for other validations too? Sahina yes. The FQDN and other pre-requisite checks we do are for RHHI deployments. And brick creation is part of backend-setup role, which executes first then the role related to RHHI run. If we put the pre-requisites as part of backend-setup role (which is run first), there might be users who would not want these pre-requisites while setting up backend. What is the expectation here?
(In reply to Sachidananda Urs from comment #8) > (In reply to Sahina Bose from comment #7) > > Sachi, I did notice the FQDN check was executed after the brick creation. > > Could the same be true for other validations too? > > Sahina yes. The FQDN and other pre-requisite checks we do are for RHHI > deployments. > And brick creation is part of backend-setup role, which executes first then > the role related to RHHI run. > If we put the pre-requisites as part of backend-setup role (which is run > first), there might be users > who would not want these pre-requisites while setting up backend. > > What is the expectation here? Sac, The point is that preliminary checks decide whether the systems are reliable for RHHI-V installation. These checks should be run before configuring anything on the system. One and only if these checks are passed, configuration step should be initiated. We need to satisfy this requirement
sas, please setup a meeting with RHHI team (QE and devel) to come to an understand about this requirement. If we add RHHI specific pre-req to backend setup, we are limiting a lot of people who do not use RHHI. Instead we have to implement these pre-requisites as pre_tasks in playbooks than in roles.
(In reply to Sachidananda Urs from comment #10) > sas, please setup a meeting with RHHI team (QE and devel) to come to an > understand about this requirement. If we add RHHI specific pre-req to > backend setup, we are limiting a lot of people who do not use RHHI. > > Instead we have to implement these pre-requisites as pre_tasks in playbooks > than in roles. Agreed! We have to discuss about that and finalize it
https://github.com/gluster/gluster-ansible/pull/70 https://github.com/gluster/gluster-ansible-features/pull/27
(In reply to SATHEESARAN from comment #11) > (In reply to Sachidananda Urs from comment #10) > > sas, please setup a meeting with RHHI team (QE and devel) to come to an > > understand about this requirement. If we add RHHI specific pre-req to > > backend setup, we are limiting a lot of people who do not use RHHI. > > > > Instead we have to implement these pre-requisites as pre_tasks in playbooks > > than in roles. > > Agreed! We have to discuss about that and finalize it It was decided after the discussion to have the prechecks in the form of ansible prechecks
(In reply to SATHEESARAN from comment #13) > (In reply to SATHEESARAN from comment #11) > > (In reply to Sachidananda Urs from comment #10) > > > sas, please setup a meeting with RHHI team (QE and devel) to come to an > > > understand about this requirement. If we add RHHI specific pre-req to > > > backend setup, we are limiting a lot of people who do not use RHHI. > > > > > > Instead we have to implement these pre-requisites as pre_tasks in playbooks > > > than in roles. > > > > Agreed! We have to discuss about that and finalize it > > It was decided after the discussion to have the prechecks in the form of > ansible prechecks sas, I didn't get your point. This is what we decided to add the checks to pre_tasks.
(In reply to Sachidananda Urs from comment #14) > sas, I didn't get your point. This is what we decided to add the checks to > pre_tasks. I just update this ticket to be consistent with information that we discussed. Nothing more
The dependent gluster-ansible bug is verified, but this bug still available in RHHI-V, as the deployment module - cockpit-ovirt - needs to bring in this change cockpit-ovirt bug - https://bugzilla.redhat.com/show_bug.cgi?id=1724035 have to be fixed
The dependent bug is on POST state
Tested the bug with cockpit-ovirt-dashboard-0.13.6-1.el7ev.noarch. The preflight check has been moved to ansible pre task, so moving the bug as verified.
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:2963