In order to reference the containing group in rules that specify the group_id parameter, one must do the following:
which is not idempotent. I propose that the rule group_id parameter accept the special keyword “this” as a means of referencing the group that contains it. Thoughts?
(I already created issue #5309 and pull request #5310 for this)
Would it not be possible have a different parameter such as group_append=True to achieve this same functionality?
Indeed it would. I’d thought of this as well but wasn’t sure which is better, a new parameter or overloading the group_id parameter, and I was struggling with what a new parameter would be named. I’m not sure that group_append describes the behavior that well, but it’s probably OK for lack of a better choice. I’m fine with whichever approach people would find most intuitive.
“which is not idempotent”
That word again 
Please translate your meaning here – does it mean it does not provide repeatable behavior if you re-run it, if so, how?
The AWS API action AuthorizeSecurityGroupIngress allows specifying a source group by id or by name, so perhaps another possibility is to add a new rule parameter group_name, then you could do the following:
Or perhaps the new parameter isn’t necessary at all and the group_id parameter could accept either an id or a name, but again this would be overloading the parameter. The AWS console actually allows specifying a source group by id or name.
Group_name sounds like a good answer here.
Generally speaking I’d like to see a lot of lookups for non-ID things where it makes sense, especially as IDs tend to hop around if removed and recreated, etc.
You currently need to execute the task twice. Once to capture the group in a register variable, then a second time to add the rule that references the group itself as a source by obtaining its id from the register variable. When you re-run the playbook, the first task destroys the rule setup in the previous execution of the second task (since all rules except those present in the task are removed), then the second task recreates it again. So the end result is the same and is repeatable, but state is unnecessarily being changed in the process. Hope that’s more clear
Yep, thanks!
OK, I’ll leave a bit more time for additional comments and in the mean time I’ll work on implementing new rule parameter group_name.