I've been playing with intersection (&) and negation (!) matches a bit lately. All very cool -- allowing me to target subsets of groups both inside a playbook and with the --limit command line option.
I'm looking at the code responsible and wondering at the intended semantics if the token following the magic symbols & and ! is empty.
For example:
ansible-playbook test.yml --list-host --limit 'all:'
give me all hosts (all hosts plus the hosts in the group/host ''),
ansible-playbook test.yml --list-host --limit 'all:!'
gives me all hosts (all hosts except the hosts in the group/host ''),
ansible-playbook test.yml --list-host --limit 'all:&'
gives me no hosts (all hosts that are also in the group/host '').
This is all logically correct, but I'm wondering if it is what people expect. The first two cases suggest (incorrectly) that the empty string is being ignored, and intuitively I expected the last case to give me all hosts as well.
Consider also playbooks with either of the following lines
hosts: my_group:!$constraint
hosts: my_group:&$constraint
If $constraint is '', then the first runs on all hosts in my_group, and the second wont run at all.
Should a constraint marker without a token be an error/warning since it is probably not what the user intended? Should the nonsensical pattern be silently dropped?
Thoughts?
K
It's doing that because there is no group named empty string.
I suppose the question is can "&" and "!" be used to prefix something
other than a group (like a host) and they can.
It's just like you can do:
hosts: fooGroup:barGroupThatDoesNotExist
and it does not yell at you about barGroupThatDoesNotExist, because
that could be a pattern, or something that may exist in another
inventory file.
I think it's not-super-critical as you have listed above, unless you
find yourself accidentally doing that too much, because we also allow
group names that don't match the inventory (by design).
--Michael
It's just like you can do:
hosts: fooGroup:barGroupThatDoesNotExist
and it does not yell at you about barGroupThatDoesNotExist, because
that could be a pattern, or something that may exist in another
inventory file.
Good point.
I think it's not-super-critical as you have listed above, unless you
find yourself accidentally doing that too much, because we also allow
group names that don't match the inventory (by design).
After describing the problem and thinking a bit more I came to the same
conclusion. The better way of achieving what I wanted ended up being
host: mygroup:$contraint
in the included file, and
- include: ../myapp/update.yml constraint='&prod:&webserver'
in the main playbook, which ends up being more explicit and flexible.
Thanks for all you fantastic work with Ansible and best of luck with AnsibleWorks.
Cheers,
Kal