Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When using multiple inventory files and nested groups order is significant #82135

Open
pva opened this issue Nov 5, 2023 · 2 comments
Open
Labels
affects_2.15 bug This issue/PR relates to a bug. P3 Priority 3 - Approved, No Time Limitation

Comments

@pva
Copy link

pva commented Nov 5, 2023

Summary

This is precisely #16116. But since it was closed and I can't reopen it, I have to open a new one. The fix in that issue fixes order only for vars, while the issue itself was about host definitions as well.

So jump to the issue itself:
When using multiple inventory files with nested groups, any inventory file that contains children referenced in an earlier inventory file is not seen and causes an error.

The patch was suggested here: ShiwenMa#1 or here 47326e8, but it fixes nothing! It just removes the error message.

This is a bug report about documented behavior: https://docs.ansible.com/ansible/latest/inventory_guide/intro_inventory.html#managing-inventory-load-order, so probably this is a feature request.

Also, if I use multiple YAML inventory files, my tests show that the order is insignificant, and everything works as expected.

Issue Type

Bug Report

Component Name

inventory

Ansible Version

$ ansible --version

ansible [core 2.15.5]
  config file = None
  configured module search path = ['/home/peter/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.10/site-packages/ansible
  ansible collection location = /home/peter/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/lib/python-exec/python3.10/ansible
  python version = 3.10.13 (main, Sep 21 2023, 18:55:47) [GCC 13.2.1 20230826] (/usr/bin/python3.10)
  jinja version = 3.1.2
  libyaml = True

Configuration

# if using a version older than ansible-core 2.12 you should omit the '-t all'
$ ansible-config dump --only-changed -t all
CONFIG_FILE() = None
DEFAULT_VAULT_PASSWORD_FILE(env: ANSIBLE_VAULT_PASSWORD_FILE) = /home/peter/.ansible_vault_password_lfstrm
EDITOR(env: EDITOR) = /usr/bin/vim
PAGER(env: PAGER) = /usr/bin/less

OS / Environment

CentOS, Gentoo Linux and everywhere

Steps to Reproduce

The inventory contains the following inventory files
1.parentgoup
2.childgroup

Contents of inventory files are
$ cat inventory/1.parentgoup

[testgroup:children]
childgroup

$ cat inventory/2.childgroup

[childgroup]
child

Command is

$ ansible-playbook playbooks/common.yml --limit 'testgroup' --list-hosts

Expected Results

playbook: playbooks/common.yml

  play #1 (all): all    TAGS: []
    pattern: [u'all']
    hosts (1):
      child

Actual Results

ERROR! /etc/ansible/inventory/1.parentgoup:2: Section [testgroup:children] includes undefined group: childgroup


### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct
@ansibot ansibot added bug This issue/PR relates to a bug. needs_triage Needs a first human triage before being processed. affects_2.15 labels Nov 5, 2023
@ansibot
Copy link
Contributor

ansibot commented Nov 5, 2023

Files identified in the description:

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

@sivel
Copy link
Member

sivel commented Nov 7, 2023

The current behavior is expected. We specifically added this check because of the risk of a user mistyping the child group name. As such we currently raise an error if the child group has not yet been defined.

We are going to look into potentially adding a configuration toggle that can change the behavior to create the group when missing, however we do not plan to change default behavior.

I should note that due to how the YAML inventory works, listing a child group actually creates it due to the structure. So it's not necessarily 1:1.

@sivel sivel added P3 Priority 3 - Approved, No Time Limitation and removed needs_triage Needs a first human triage before being processed. labels Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects_2.15 bug This issue/PR relates to a bug. P3 Priority 3 - Approved, No Time Limitation
Projects
None yet
Development

No branches or pull requests

3 participants