Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add ansible.cfg setting to suppress duplicate group host warnings #32283
This PR adds a setting called
For example, currently with the following inventory file:
If you run an ansible playbook you will get the following warning:
This warning was introduced in Ansible 2.3 (#22519).
In some use cases, this configuration is normal. For example, if you are performing cloud deployments and want to target a specific "environment", setting the host and group name to the same value allows you to define your "environment" settings in
With this PR users now have the option to suppress the above warning by adding the following configuration to
referenced this pull request
Oct 28, 2017
@bcoca - I tend to agree, although that is probably more a wider aspiration for the general Ansible warning system itself, rather than the scope of this PR. I.e. it would require a warning classification mechanism, etc, which is a design and creational concern.
This is a tactical fix for a seemingly tactical warning that was introduced in Ansible 2.3, which causes spurious warnings for Docker and Cloud environments where setting the group and host name to the same value is a very effective approach.
The original warning addresses an issue where you inadvertently make a host a member of a group with the same name via group inheritance - see https://gist.github.com/willthames/9614054#file-hosts
In my use case, I actually explicitly set the group/host relationship so it's immediately obvious:
And in the case of Docker dynamic inventory, it seems it also follows a similar behaviour.
Therefore I think having the warning enabled by default is a good thing (protects against the accidental scenario it was designed for), but having the ability to disable it allows for other valid use cases (remembering the user has to explicitly disable this warning, implying they understand why).
Actually, I found that the errors I was seeing were mostly about groups auto-created by the ec2.ini settings. Choosing not to group all those services that are set to "True" by default prevents the messages.