- In this video, I want to talk
about managing failure using the fail module.
So what is going on?
Well, Ansible, by nature looks at the exit status
of a task to determine whether it has failed or not.
And this may lead to failures occurring
when nothing really is going wrong.
When any task fails, Ansible aborts the rest
of the play on that host and continues with the next host.
There are a couple of solutions that you can use
to change the default behavior of dealing with failures.
In Ansible, you can use ignore_errors
in a task or in a play header to ignore_failures.
And you can use force_handlers in a play header
to force a handler that has been triggered
to run even if another task has failed.
We've already seen the last one.
You can also define your own failed status.
As Ansible only looks at the exit status of a failed task,
it may think that the task was successful,
but this is not the case.
To be more specific, you can use failed_when.
That allows you to specify what to look for
in command output to recognize failure.
And there's also the fail module.
The failed_when keyword can be used in a task
to identify when a task has failed.
The fail module can be used to print a message
that informs why a task has failed.
To use failed when or fail the result
of the command must be registered,
and the registered variable output must be analyzed.
When using the fail module, the failing task
must have ignored_errors set to yes,
because the essence of the fail module
is that you want to do something
if a failure occurs.
And if you want to do something after the failure,
well, it's mandatory to use ignore errors,
because otherwise play execution will be aborted
on that specific host.
Let's go check out a couple of examples.
So to start with, let's have a look at failure.yml.
So what is this?
This is a pretty simple example of failed_when.
And in this example, we will run,
well, it's not really a script, we run a command.
The command is echo hello world.
We use ignore_errors because we want the play to continue
to the next test, no matter what.
Then we register command result,
and we print failed_when,
world in command_result.stdout.
You have already worked with register.
So hopefully you have seen that anytime you use register,
register creates a variable name.stdout
with the result of the actual command.
Now, it needs no imagination to imagine
that hello world is probably going to have the text,
world in command_result.stdout.
But here we are telling Ansible that it needs
to fill if it finds this specific text.
Of course that doesn't make much sense,
but it allows us to understand how it is working.
Then, the next, task is debug.
Message hello, just to see if we get there.
So let me run it.
Ansible-playbook on failure.yml.
And there you can see that it is failing
because we told it to.
But, we have ignored failure
and we are getting to the next part anyway.
Let's have a look at another example
which is failure2.
So what do we have in failure2?
We are running on all hosts
and we are doing something impossible.
Lvol, lvolv is checking logical volumes.
It's an Ansible module that checks for logical volumes.
So it checks to see if we have logical volume
with the name, lvnothing, and a volume group
with the name vgnothing, and a size of one gigabyte.
And we register the output of the command in command result.
Again, ignore errors, yes.
That is because we want it to continue
regardless of the actual result of the command.
Next, just for debugging purposes.
And I would advise you, I told you before
I always would advise you use debugging
kind of variables to show the result
so that you know, what's going on.
So I want to print the contents
of this variable command_result.error,
and then I'm printing nice error message after the failure.
That is where the fail module is coming in.
And the fail module is printing volume group
doesn't exist, when not found in command_result.error.
The thing is that lvol is trying to work on some volumes.
We are most likely getting an error message
and that is when fail should print a nice error message.
So fail is convenient if you want to get out
of desk execution while showing a nice error message.
So here is the result.
We can see the result of the command, vgnothing, not found.
This is also in command_result.error.
And then we have the nice failure message.
It's still red because it's a failure message,
but the purpose here is that we print something
nice and readable for our users and that was successful.