New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ansible.cfg setting to suppress duplicate group host warnings #32283

Open
wants to merge 1 commit into
base: devel
from

Conversation

Projects
None yet
5 participants
@mixja
Contributor

mixja commented Oct 28, 2017

SUMMARY

This PR adds a setting called display_duplicate_group_host_warnings to the ansible.cfg file which can be used to display/suppress warnings with the target host name is the same as the group name.

For example, currently with the following inventory file:

[dev]
dev ansible_connection=local

If you run an ansible playbook you will get the following warning:

 [WARNING]: Found both group and host with same name: dev

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 group_vars. Note there are comments on #22519 indicating this is an issue for docker.py dynamic inventory as well.

With this PR users now have the option to suppress the above warning by adding the following configuration to ansible.cfg:

[defaults]
...
...
display_duplicate_group_host_warnings = False
ISSUE TYPE
  • Feature Pull Request
COMPONENT NAME

ansible

ANSIBLE VERSION
ansible 2.5.0
  config file = None
  configured module search path = [u'/Users/jmenga/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python2.7/site-packages/ansible
  executable location = /usr/local/bin/ansible
  python version = 2.7.14 (default, Sep 25 2017, 09:54:19) [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)]
@mixja

This comment has been minimized.

Contributor

mixja commented Oct 28, 2017

please re-run CI as failures were due to transient yum repository failures

@ansibot ansibot added the bot_broken label Oct 28, 2017

@bcoca

This comment has been minimized.

Member

bcoca commented Oct 29, 2017

@mixja you disabled the bot, that command is not used for that purpose, you can close/open the ticket or update the branch to force rerun. In any case, i'm triggering it manually.

@bcoca bcoca removed the needs_triage label Oct 29, 2017

@bcoca

This comment has been minimized.

Member

bcoca commented Oct 29, 2017

As for the PR itself, i'm not sure if we want to create a config setting per possible warning.
A better approach would be a generic setting to choose which warnings to ignore.

@mixja mixja force-pushed the mixja:suppress_group_host_warnings branch Oct 29, 2017

@mixja

This comment has been minimized.

Contributor

mixja commented Oct 29, 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.

@bcoca

This comment has been minimized.

Member

bcoca commented Oct 30, 2017

Well, i'm not sure if it is effective as one entry masks the other, same as in your original use case. That masking is why we added the warning in the first place as people were hitting obscure errors due to it.

@mixja

This comment has been minimized.

Contributor

mixja commented Oct 30, 2017

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:

[production]
production ansible_connection=local

[staging]
staging ansible_connection=local

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).

@mixja mixja force-pushed the mixja:suppress_group_host_warnings branch to 04f34cd Nov 1, 2017

@mixja

This comment has been minimized.

Contributor

mixja commented Nov 1, 2017

Looks like this issue is also related - #24273

@mattclay mattclay removed the bot_broken label Nov 10, 2017

@ansibot ansibot added stale_ci and removed needs_revision labels Nov 10, 2017

@mixja

This comment has been minimized.

Contributor

mixja commented Nov 19, 2017

bot_status

@ansibot

This comment has been minimized.

Contributor

ansibot commented Nov 19, 2017

Components

examples/ansible.cfg
support: core
maintainers:

lib/ansible/config/base.yml
support: core
maintainers:

lib/ansible/inventory/data.py
support: core
maintainers:

Metadata

waiting_on: ansible
changes_requested_by: null
needs_info: False
needs_revision: False
needs_rebase: False
merge_commits: []
mergeable_state: clean
shippable_status: success
maintainer_shipits (module maintainers): False
community_shipits (namespace maintainers): False
ansible_shipits (core team members): False
shipit_actors (maintainer or core team member): None
shipit_actors_other:

click here for bot help

@ansibot ansibot added feature and removed feature_pull_request labels Mar 2, 2018

@scottlackey

This comment has been minimized.

scottlackey commented May 17, 2018

I'd really like this feature as it would clean up a lot of junk warnings in the output my developers see when they run their deploys.

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.

@ansibot ansibot added the core_review label Oct 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment