You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure how possible this is, but I was recently trying to update the pulsys user keys on a box via Tower, and was misled because the job reported success even though it did not find any servers that matched my parameters. This isn't as much a problem when running from the command line, but it's easier to miss when running from Tower.
Level of urgency
High
Moderate
Low
Why is this maintenance needed?
The job to update the pulsys user keys is one that can often only be run from Tower. In this context, it can be easy to miss if it does not actually run on your host, since the output doesn't update without extra steps and the job reports success overall. It would be more intuitive if this particular job failed if it did not find any matching hosts.
Acceptance criteria
Ansible Tower reports a failure if "Update pulsys user keys" is run and doesn't match any hosts
Implementation notes, if any
I'm not sure if we would want to change the overall HOST_PATTERN_MISMATCH configuration, or whether it would be a way to configure it by playbook?
The text was updated successfully, but these errors were encountered:
I wonder if we can fix this with a fail pre-task - something like:
- name: Fail playbook when no hosts match
ansible.builtin.fail:
msg: The playbook did not add keys to any hosts, please try again.
failed_when: "ansible_play_hosts is null"
Hm, thinking a bit more about this . . . the challenge with this particular playbook is that it has two plays - one runs on PUL-only and CDH-only boxes, installing the correct group of keys on each server; the other runs on "shared" boxes, installing both groups of keys on those servers. For a lot of servers and groups, I would expect one or the other play to return no hosts matched when the playbook is doing the right thing. For example, if we update keys on the postgresql boxes, the first play should return no hosts matched. So we don't want that to make the whole playbook error out unless we stop using --limit. I don't immediately know of a way to set a fail task at the playbook level, to force failure if BOTH plays returned no hosts matched.
What maintenance needs to be done?
I'm not sure how possible this is, but I was recently trying to update the pulsys user keys on a box via Tower, and was misled because the job reported success even though it did not find any servers that matched my parameters. This isn't as much a problem when running from the command line, but it's easier to miss when running from Tower.
Level of urgency
Why is this maintenance needed?
Acceptance criteria
Implementation notes, if any
I'm not sure if we would want to change the overall HOST_PATTERN_MISMATCH configuration, or whether it would be a way to configure it by playbook?
The text was updated successfully, but these errors were encountered: