RE: [https://github.com/ansible/ansible/pull/5430](https://github.com/ansible/ansible/pull/5430)
The intent here was to make it possible for users of the ec2 inventory
module to be able to directly address hosts using groups in the format of
'<tag>=<value>'
The patch does not change existing behavior, and keeps the legacy format of
host groups for tags to look like 'tag_<tag>_<value>' by default.
Say I have a tag named 'role' across some subset of instances, and the
value of this tag can be set to things like 'builder', 'packer' or
'shipper'.
Using the ec2 inventory plugin as is, to run a playbook across all host
instances whose 'role' tag is set to 'builder', one would need to:
ansible-playbook -i ./inventory ./playbooks/builders.yml -l tag_role_builder
It would be nice to simply be able to do:
ansible-playbook -i ./inventory ./playbooks/builders.yml -l role=builder
And now you can also define your playbooks to have:
----
hosts: role=builder
....
That's all this pull request does, with no impact on backwards
compatibility.
So my concern here is this – we can already access tags of various groups as tag_Key_Value, thus the underlying change is cosmetic.
If different folks adopt each convention at equal frequency, it then confuses the way we talk about ec2 playbooks.
One must not only show the playbook, but also what version of the ec2 inventory script they were using and the value of this particular setting.
(For instance, all the examples you might share on Ansible-project list when helping users wouldn’t work for them, because their tags would be named differently)
Playbooks developed for ec2 using group_by would then only work for half of the users and sharing would be limited.
(Further, we’d have to surface this setting in AWX, which seems like a waste of a checkbox that would have to be accompanied by a rather confusing tool tip)
As such, I don’t see the need for this to be in core, however you can of course completely use your own version of the ec2 inventory script with whatever customizations you like.
Unlike some pieces of code, this being a plugin allows you to continue to use it in any way you like, without this contribution needing to be folded back into core and causing the split everyone’s conventions and examples above.
Those are valid points; I don’t disagree. Thanks.