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
internal-error caused by "no hosts matched the subscripted pattern" #2422
Comments
I checked and this error happens only when you use
This comes from ansible itself, so we have little control over it but I suspect that you could use jinja to avoid this error. Basically the linter found a flaw in your logic, as your code does not work well with host groups of size 0 or 1 ( |
I should have added that my scenario is molecule where it's rather hard to address certain vms by name, as they are dynamically generated on parallel runs (which I'm doing). Logically the test works fine, it's just the linter that is unhappy. I'll try to figure out some workaround with jinja, good hint, thanks. |
I checked and TBH, I do really see this as a bug, more of a feature! ;) -- Still I will consult with other teammates. Molecule scenarios are just playbooks, no reason to treat them different. Because the ansible originating error is not really giving a direct escape solution, I would likely keep the bug open as we might be able to spot it and return an improved error message that includes an example of "resilient way to selecting a host" (example above). |
Yeah, that seems to be working, thanks. Maybe there's a way in molecule to address hosts differently that I don't know about. What I do is creating 2 (Hetzner) VMs like this: platforms:
- name: "${VM_PREFIX:-$USER}-wireguard-default-1"
name_length_limit: 64
server_type: cpx11
image: debian-10
location: hel1
networks:
wireguard-network:
ip_range: 10.0.0.0/16
subnet:
ip: 10.0.66.42/24
- name: "${VM_PREFIX:-$USER}-wireguard-default-2"
name_length_limit: 64
server_type: cpx11
image: debian-11
location: hel1
networks:
wireguard-network:
ip_range: 10.0.0.0/16
subnet:
ip: 10.0.66.43/24 As you know, - name: Converge
hosts: "{{ 'all[1]' }}"
tasks:
- name: Set preshared key for client
ansible.builtin.set_fact:
wg_psk: somecrazysecrethere
- name: Converge
hosts: all[0]
tasks:
- name: Set private_network_ip for server
ansible.builtin.set_fact:
private_network_ip: 10.0.66.42
- name: Converge
hosts: all
tasks:
- name: Import wireguard
ansible.builtin.import_role:
name: wireguard
vars:
wg_peers:
- "{{ groups['all'][0] }}"
- "{{ groups['all'][1] }}"
wg_net_cidr: 10.0.187.1/24 So to sum it up, I need to do certain things on one host and other things on the other. But I can really live with the given workaround. Thanks! |
This bug is basically caused by a pelicular behavior of ansible when you feed it - name: Reproduce bug
hosts: all[1]
That is bit hilarious because during linting we explicitly fed ansible Running without any inventory allows both to work but you get the extra warnings. In general, I do not find indexing of a host group without fallback as a good practice as it assumes a group has multiple hosts inside, when in fact it can even have none! That is why I would recommend anyone using I am not sure what we can do to improve the experience here. |
Since it's a rare edge case it's probably good enough to have it documented in this issue so people find the workaround. Edit: follow the documentation that has been added after my comment. It shows a cleaner solution. |
Summary
When I address a host that ansible-lint does not know about, it throws an internal-error.
Issue Type
Ansible and Ansible Lint details
OS / ENVIRONMENT
5.15.65-1-MANJARO #1 SMP PREEMPT Mon Sep 5 10:15:47 UTC 2022
STEPS TO REPRODUCE
foo.yml
ansible-lint --exclude venv -v foo.yml
Desired Behavior
No linting errors reported.
Actual Behavior
But the following (not specifying the playbook by name) works fine:
Why do I care? The first is what the vscode plugin seems to be doing
The text was updated successfully, but these errors were encountered: