Closed jon4hz closed 7 months ago
In theory, if you make TLS mandatory, the previous block fails and triggers the rescue. You also can't get rid of the first attempt done without TLS, otherwise when you set up the server for the first time you won't have TLS available to do the setup.
This was working a few years ago when I was running a playbook using this role in production, so either failed_when didn't prevent the rescue block from running (this may have changed at some point) or it hasn't been working as intended for a while and nobody ever noticed the problem
Actually I've been playing around with that setting a lot and I've never seen that task fail. So I'm fairly sure the rescue block isn't even needed. But I'll verify that on Monday again.
As for the rescue block: I did a quick test and ansible doesn't trigger the rescue tasks unless one of the tasks inside the block actually fails. Using failed_when: false
puts the task in state where it cant fail anymore, or at least doesn't report it as failed ever.
E.g.
- hosts: localhost
gather_facts: false
tasks:
- block:
- ansible.builtin.assert:
that: false
failed_when: false
rescue:
- ansible.builtin.debug:
msg: Never happens :(
Hey,
What exactly is the purpose of the
rescue
block in the configure_tls_enforcing.yml file? I think that part is never triggered, because theConfigure enforcing of TLS
tasks has anfailed_when: false
attribute.