Host parameters are available as variables when the playbook runs so instead of rendering the template differently for different hosts, it is preferred to have the template render to the same playbook for all hosts and let ansible do different things with it.

---
- name: A playbook to test host parameter
  hosts: all
  gather_facts: true
  tasks:
    - name: My Script
      ansible.builtin.script:
        cmd: /usr/bin/echo "rebooting"
      when: patching_reboot

This issue exists and is known. It is an outcome of trying to fit a 1:n tool (ansible) to an already existing 1:1 model (non-ansible remote execution). There used to be a time where we spawned a separate ansible-playbook instance for every single host in the job and switching to running a single ansible-playbook instance per batch introduce this issue, but the original way didn't scale. I know this is unfortunate if you're used to using non-ansible based remote execution in Satellite, but thinking about ansible from satellite as "just ansible" rather than something else helps a bit.

> The job template will render according to the very first host's host parameter

Under the hood the job template gets rendered separately for each host, but then all the rendered variants are ignored except for the first one. As far as I know Ansible itself does not allow running multiple playbooks against multiple hosts with a single ansible-playbook invocation so there's that.

We could try comparing the rendered playbooks, grouping them and then spawning a separate instance of ansible for each distinct playbook, instead of spawning a single one for the entire batch, but so far we didn't have the need for it and this particular BZ doesn't sound like anything that would change our stance towards that. I'd suggest embracing ansible and leaning into ansible-native ways of doing conditionals, which will always behave better. Once we find a use case which cannot be expressed natively in ansible then we may revisit this, but until that happens I don't really see us investing time into this.

However, the issue is there, there's no denying that, but we could at least document the recommended way of doing things to prevent people from running into this, especially if we consider the ansible-native way to be superior in probably all regards.

https://github.com/theforeman/foreman-documentation/pull/3065

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.