gdeploy section should provide an option to abort the configuration when encountered a failure

[satheesaran]

Hi,

gdeploy should provide an option to abort the configuration, when there is a failure encountered.

I agree that some use case, may require gdeploy to continue even when there is a failure.
But certain cases doesn't seem valid when gdeploy continues post failure, and ends the system in a bad state.

For example, when the installation of vdsm fails due to some reasons, continuing with the setup process, would make all the lvm commands to hang ( this is the known issue )
Take another case, when vg create failed, but gdeploy continues to create thin_pool, thin_lv, etc, doesn't seem meaningful.

So the solution is to have a option in each of the section like - "abort_on_failure", where the user can customize the behavior. By default this option could be enabled, so gdeploy stops execution on encoutering a failure, which is what most of the usecase expect.

[sac]

Commit b30228d fixes the issue. There are multiple commits for various checks. Documented in examples.

[satheesaran]

@sac , I see the change is only under the sections [volume] and [peers].

But this is not all the requirement.
It would be good to have generic 'ignore_on_failure', underneath all sections.

Say, my can fail due to package missing, or network issues, in another case, my pv creation may fail due to bad disks, on other hand, setting up NTP may file, if /etc/ntp.conf file is not present.

So, the requirement is to have a catch_all failure scenario

@sac - what do you think ?

[sac]

@satheesaran currently the way gdeploy works is, each section is a different entity. They do not share any data between them. We do not manage any key/value store (as of now). So, currently the solution is to provide exit option to every critical section.

For example if you think gdeploy should abort if yum does not succeed. You can limit it to yum.

I propose we keep this, and once I add key/value store for the process. We can go for global abort_on_error.