Skip to content

ansible-pull: checkout step ignores --limit and resolves short hostname as inventory group name #86854

@picarica

Description

@picarica

Summary

so quick pre text: i had two servers called rancid but both on totally different networks, but what was happneing that one host was running ttasks for both hosts.

  1. The auto-limit includes the short hostname (host.split('.')[0]), which will collide with inventory group names. Ansible's --limit resolves tokens as both hostnames and group names. If a machine's short hostname matches a group name (e.g., hostname rancid.joj.sk produces short name rancid, which matches group rancid), the checkout step will process all hosts in that group instead of just the local host. This is the line that produces the problematic token:

hostnames = ','.join(set([host, node, host.split('.')[0], node.split('.')[0]]))

  1. The checkout step ignores the provided --limit. Even when i explicitly pass --limit rancid.joj.sk, the checkout command is always built with the auto-generated limit_opts. --limit (context.CLIARGS['subset']) is only checked when building the playbook command, not the checkout command. This means there is no way for the me to override the broken checkout limit.

The affected code is entirely within PullCLI.run() in lib/cli/pull.py. The fix would be to either use context.CLIARGS['subset'] for the checkout step when provided, or to avoid including the short hostname in the auto-limit (or at least prefix it to prevent group-name collision, e.g. by using an Ansible host pattern that only matches hostnames, not groups).

#*/20 * * * * root /usr/bin/ansible-pull --checkout=master -U https://user:[email protected]/joj/ansible.git --directory /usr/local/ansible/pull -i /usr/local/ansible/pull/hosts.yml /usr/local/ansible/pull/site.yml >/dev/null
i had it like this in cron. and it was working fine until i came accross this issue.

so far i fixed the problem by renaming my rancid role ro rancid_servers. but this shouldnt happen. or should be more easily debuggable. thank you. if you need any more info ill provide it happily. this took me few days to figure out why was this happening.

Issue Type

Bug Report

Component Name

pull.py

Ansible Version

$ ansible --version
ansible [core 2.17.12]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.10.12 (main, Mar  3 2026, 11:56:32) [GCC 11.4.0] (/usr/bin/python3)
  jinja version = 3.0.3
  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() = /etc/ansible/ansible.cfg
DEFAULT_LOG_PATH(/etc/ansible/ansible.cfg) = /var/log/ansible/ansible.log

OS / Environment

PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.5 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

Steps to Reproduce

# this in site.yml
- hosts: rancid_servers
  roles:
    - rancid
# this in hosts.yml
rancid:
  hosts:
    rancid.myweb.sk:
    rancid.dc1.differentweb.sk:

Expected Results

it should look at whole fqdn first then fallback to short hostname not the other way around.

Actual Results

all my tasks were running on both server 
2026-04-16 09:21:00,363 p=837897 u=root n=ansible | TASK [common : Check if ansible is run on supported OS] ************************
2026-04-16 09:21:00,407 p=837897 u=root n=ansible | skipping: [rancid.myweb.sk]
2026-04-16 09:21:00,420 p=837897 u=root n=ansible | skipping: [rancid.dc1.differentweb.sk]

Code of Conduct

  • I agree to follow the Ansible Code of Conduct

Metadata

Metadata

Assignees

No one assigned

    Labels

    affects_2.17bugThis issue/PR relates to a bug.needs_triageNeeds a first human triage before being processed.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions