Clarification on host targeting in playbooks

[xorinzor]

Summary

I ran into a scenario where I had to target a single host, instead of a group. Since both appeared to use the same hosts: syntax this got me thinking, what if both a host and group share the same name? What is the processing order?

Example inventory:

web
node
[web]
web
node

Example playbook:

---
- hosts: web
  tasks:
    - debug: 'msg=test'

Using these files for a quick test shows that Ansible does output a warning, but proceeds by only selecting the host web.
It's not until you set hosts to be web:* that it will select all hosts within the group web instead (which, given the child selector, makes sense).

This documentation page about targeting hosts doesn't appear to mention anything about the order in which ansible selects the matching patterns.

Although I'm sure it's not considered best-practice, nor recommended to have a host share the same name with a group, I think the documentation would still benefit from clarification on what behavior to expect from Ansible.

Given my test it would appear that Ansible prioritizes a host over a group with the same name, until a child-selector is provided. This however, is just an assumption, and would benefit from actual documentation to prevent any unexpected scenarios.

Issue Type

Documentation Report

Component Name

playbook

Ansible Version

$ ansible --version

ansible 2.9.27
  config file = /etc/ansible/ansible.cfg
  configured module search path = [u'/home/ansible/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible
  executable location = /bin/ansible
  python version = 2.7.5 (default, Nov 16 2020, 22:23:17) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44)]

Configuration

# if using a version older than ansible-core 2.12 you should omit the '-t all'
$ ansible-config dump --only-changed -t all

<no output>

OS / Environment

N/A

Additional Information

It would help clarify the expected behavior of Ansible in edge-cases like this.

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibot]

Files identified in the description:

• lib/ansible/cli/playbook.py

If these files are incorrect, please update the component name section of the description or use the component bot command.

[flowerysong]

Personally, I don't think this needs to be documented. You're not supposed to give hosts and groups the same name, so leaving that as undefined behaviour is fine.

Mainly, though, I wanted to point out that hosts: web:* isn't a "child selector" (I'm not even sure what that's supposed to mean.) It's a host pattern that contains two sub-patterns; the first one matches the host web, and the second matches all hosts. It's exactly the same result as hosts: '*', just in a more confusing package.

[xorinzor]

Even though you're maybe not supposed to, there's currently nothing stopping you from doing it, and Ansible will happily execute the playbook without any kind of confirmation by the user.

If this is something that's not supposed to happen Ansible should probably throw an error and prevent the execution to prevent any unwanted or accidental scenarios.
Otherwise, the code has to resolve the hosts property one way or another, and it would be better to have the priority documented.

As for the explanation, thanks. I wasn't aware of that. I only just started learning Ansible.

[bcoca]

not sure why this is not supposed to happen, Ansible is just executing what you ask it to, there is no real way to know that it does not really match your intentions.

needs_info

[xorinzor]

That was my idea too.

The way I'm seeing it:

• If it's unintended / unsupported functionality, execution should probably be prevented
• Otherwise, it'd help to have documented what the expected behavior of hosts: will be. Whether Ansible will select a host or group first (or perhaps depending on the order in inventory, whatever matches first?). IMO more documentation is always better.

[sivel]

I believe the warning should just be extended to indicate that the group of the same name can not be targeted by limits. It still works in the sense that group_vars and such will apply, and groups.whatever will still exist.