Bug 1341484 - [RFE] provide an option to the user to abort setup using gdeploy when one of the action fails
Summary: [RFE] provide an option to the user to abort setup using gdeploy when one of...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: gdeploy
Version: rhgs-3.1
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: RHGS 3.2.0
Assignee: Sachidananda Urs
QA Contact: RamaKasturi
URL:
Whiteboard:
: 1346253 1346652 (view as bug list)
Depends On:
Blocks: Gluster-HC-2 1351503
TreeView+ depends on / blocked
 
Reported: 2016-06-01 07:41 UTC by RamaKasturi
Modified: 2017-03-23 04:57 UTC (History)
8 users (show)

Fixed In Version: gdeploy-2.0.1-8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-23 04:57:04 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:0483 normal SHIPPED_LIVE gdeploy bug fix and enhancement update 2017-03-23 08:56:29 UTC

Description RamaKasturi 2016-06-01 07:41:36 UTC
Description of problem:
As of now  if any of the action fails with gdeploy it continues with the setup instead of aborting it. Do not continue with the next actions if one of the action fails.

Version-Release number of selected component (if applicable):
gdeploy-2.0-16.el7rhgs.noarch

How reproducible:
Always

Steps to Reproduce:
1. Install gdeploy
2. Edit hc.conf file to setup HC environment.
3. Make yum install to fail.

Actual results:
Even when install fails it tries to continue with other actions.

Expected results:
When one of the action fails abort the setup and do not proceed further.

Additional info:

Comment 2 SATHEESARAN 2016-06-16 08:11:24 UTC
*** Bug 1346253 has been marked as a duplicate of this bug. ***

Comment 3 SATHEESARAN 2016-06-16 08:21:48 UTC
gdeploy should provide the option to abort the installation when the particular section fails.

What happens with HCI installation, if something fails, gdeploy doesn't exit there, but continues to the next step, which lead to total misconfiguration.

Take for example, if the creation of vg fails, then there is no point in creation of lv1 ( thick-pool ), lv2 ( thin-pool ), lv3 ( thin lv), lv4 (thin-lv )

Expected - 
Provide an option in each of the section - 'abort_on_failure=<val>' - where val can be 0 or 1.

Comment 4 Sahina Bose 2016-07-28 07:35:15 UTC
During workshop, we found the lack of this feature a big issue. If at any step, actions fail - for instance LV creation fails - gdeploy continues ahead but bricks are mounted at root rather than created LV.

We need this RFE to be taken in.

Comment 5 Sachidananda Urs 2016-07-28 10:33:46 UTC
*** Bug 1346652 has been marked as a duplicate of this bug. ***

Comment 7 RamaKasturi 2016-12-08 10:53:40 UTC
Hi Sac,

   what is the fix here? Do i need to add some variable @ all sections so that it does not continue to other steps when the previous one fails ? Could you please add the patch to this bug which fixes this issue?

Thanks
kasturi

Comment 8 Sachidananda Urs 2016-12-12 07:09:33 UTC
Hi Kasturi,

I've documented the flags under every feature and can be found at: http://gdeploy.readthedocs.io/en/latest/features.html

This is how it works. Under lv section you can set

[lv]
...
...
...
ignore_lv_errors=no

[yum]
.
.
.
ignore_yum_errors=no

Like that. And if there are any errors under that section gdeploy
will exit and will not continue from there on.

https://github.com/gluster/gdeploy/commit/1ba725e795
https://github.com/gluster/gdeploy/commit/7f2e8f3ea0
https://github.com/gluster/gdeploy/commit/1acd414ba4

Are some of the commits that fixes the bug

Comment 9 RamaKasturi 2016-12-16 06:23:47 UTC
Moving this bug back because i see that even after having ignore_yum_errors=no and ignore_register_errors=no gdeploy continues to the next step and does not exit.

Comment 10 Sachidananda Urs 2016-12-16 09:48:18 UTC
Commit: https://github.com/gluster/gdeploy/commit/8a656abf5f7871 fixes the issue.

Comment 11 RamaKasturi 2016-12-22 07:41:59 UTC
Moving this bug back as i see that in the setup-cache section i have added the line ignore_lv_errors=no and i gave a device which does not exist. I expected create logical volume fails and gdeploy just exits. But it just continues.

Comment 12 Sachidananda Urs 2016-12-22 10:52:18 UTC
Commit: https://github.com/gluster/gdeploy/commit/5545054a fixes the issue.

Comment 13 RamaKasturi 2016-12-23 10:01:17 UTC
Verified and works fine with build gdeploy-2.0.1-8.el7rhgs.noarch.

With the above feature in gdeploy i see that when ever a step fails gdeploy just exits and does not proceed further. If user wants to proceed further even if any of the section fails he needs to a add a flag called ignore_blah_errors=yes.

This feature is not completely implemented and there are still some caveats to this.

1) Run a command in shell commands does not have this feature.
2) Add / delete services does not have this feature.
3) start/stop/restart/reload services does not have this feature.
4) setup_cache section does not have this feature.
5) Running a shell script does not have this feature.
6) Update-file does not have this feature.

Will raise another bug for implementing this feature for the above listed ones.

When i say "<x> does not have this feature" what i mean here is even if the step fails gdeploy just ignores the errors and continues with the next steps and there is no option provided for user to add a flag like <ignore_blah_errors>=no so that it does not proceed.

Comment 14 SATHEESARAN 2017-01-05 14:16:47 UTC
(In reply to RamaKasturi from comment #13)
> Verified and works fine with build gdeploy-2.0.1-8.el7rhgs.noarch.
> 
> With the above feature in gdeploy i see that when ever a step fails gdeploy
> just exits and does not proceed further. If user wants to proceed further
> even if any of the section fails he needs to a add a flag called
> ignore_blah_errors=yes.
> 
> This feature is not completely implemented and there are still some caveats
> to this.
> 
> 1) Run a command in shell commands does not have this feature.
> 2) Add / delete services does not have this feature.
> 3) start/stop/restart/reload services does not have this feature.
> 4) setup_cache section does not have this feature.
> 5) Running a shell script does not have this feature.
> 6) Update-file does not have this feature.

Also [volume] section doesn't obey the generic ignore_errors=no, so one need to have 'ignore_volume_errors=no' explicitly for this section, in order to halt gdeploy execution on failure

> 
> Will raise another bug for implementing this feature for the above listed
> ones.
> 
> When i say "<x> does not have this feature" what i mean here is even if the
> step fails gdeploy just ignores the errors and continues with the next steps
> and there is no option provided for user to add a flag like
> <ignore_blah_errors>=no so that it does not proceed.

Comment 15 Sachidananda Urs 2017-01-23 13:04:30 UTC
(In reply to RamaKasturi from comment #13)
> Verified and works fine with build gdeploy-2.0.1-8.el7rhgs.noarch.
> 
> With the above feature in gdeploy i see that when ever a step fails gdeploy
> just exits and does not proceed further. If user wants to proceed further
> even if any of the section fails he needs to a add a flag called
> ignore_blah_errors=yes.
> 
> This feature is not completely implemented and there are still some caveats
> to this.

You are right. Currently due to a bug it is inconsistent in a few places.
In some modules ignore_blah_errors is `yes' and in some it is `no' (`no'
is due to a bug). Though it is desirable to have no in some places, I would
like to to keep it uniform, so that it is not confusing to users.

Currently fixing the above modules to `yes'. In future releases we need
to have a discussion and come to a consensus on this requirement.

Comment 17 errata-xmlrpc 2017-03-23 04:57:04 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://rhn.redhat.com/errata/RHEA-2017-0483.html


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