Have "Update pulsys user keys" job report failure on Tower if no hosts are found

[maxkadel]

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

• [ ] High
• [ ] Moderate
• [x] 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?

[acozine]

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"

[acozine]

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.