Hi there,
I'm wondering if it is planned (or already possible) to allow host
limits/subsets to be specified in individual plays.
E.g. if I have a webservers group, a debianservers group and a redhatservers
group, it would be useful to have two plays, one to install apache (say)
using an apt task and one to install it via yum. In the following example I
use the "limit" parameter as that matches the command line switch in
ansible-playbook. In the code the keyword "subset" seems to be preferred:
I have no problem with patches to allow limit groups to be set in
play. I could see this being particularly useful when used
with the group_by module.
If the CLI --limit flag is used it should only set the limit for those
plays that do not have a limit set.
---
- hosts: webservers
- limit: debian
- tasks:
- apt: ...
FYI -- Putting a dash in front of everything above is incorrect, as a
dash indicates the start of a new list entry.
- hosts: webservers
- limit: redhat
- tasks:
- yum: ...
Please note that this is just an example, and that the real question is how
to have a play run on an intersection of host groups. At the moment union
(with group1:group2) and difference (with group1:!group2) are possible, and
it's only intersection that is lacking.
Agreed
I have no problem with patches to allow limit groups to be set in
play. I could see this being particularly useful when used
with the group_by module.
OK, I’ll look into implementing something. Should I stick with the “limit” keyword?
If the CLI --limit flag is used it should only set the limit for those
plays that do not have a limit set.
Should it not be that the two instances of limit are combined (intersected with each other)?
I.e. if I have both debian and redhat webservers in London and New York, and I run the above plays with CLI --limit london, that shouldn’t be ignored should it? Rather only debian and redhat webservers in london should be touched…
FYI – Putting a dash in front of everything above is incorrect, as a
dash indicates the start of a new list entry.
Ah, typo(s) 
That sounds more more logical to me, too.
Yeah, keeping with the CLI keywords seems best.
I have no problem with patches to allow limit groups to be set in
play. I could see this being particularly useful when used
with the group_by module.
OK, I'll look into implementing something. Should I stick with the "limit"
keyword?
If the CLI --limit flag is used it should only set the limit for those
plays that do not have a limit set.
Should it not be that the two instances of limit are combined (intersected
with each other)?
It should work EXACTLY like the command line, in fact, all this would
be doing would be sourcing the data from the play object rather than
the CLI value, if one was set.
I.e. if I have both debian and redhat webservers in London and New York, and
I run the above plays with CLI --limit london, that shouldn't be ignored
should it? Rather only debian and redhat webservers in london should be
touched...
that is pretty much what it does, right?
But if the CLI --limit was only applied to play objects without their own limit (which is what I thought you meant with “If the CLI --limit flag is used it should only set the limit for those plays that do not have a limit set”), then in my example above the CLI --limit london would be ignored and the play object limits “debian” and “redhat” used instead (and servers in NY would be affected too). No?
Oh, that.
The limit system is presently only one level of limiting, it must
appear somewhere in the limit group.
I'd accept patches to make it more additive.