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)
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.
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:
ec2_group:
name: mygroup
rules:
proto: all
group_name: mygroup
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.
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