add_host followed by local_action adds 127.0.0.1 to inventory in following plays

[c0rner]

Issue Type:

• Bug Report

Ansible Version:

1.9.3 from pypi

Ansible Configuration:

Using default configuration

Environment:

Mac OS X 10.10.5

Summary:

I've actively been using a role to add host to new dynamic groups for a while and it has been working fine until today when I added a local_ action to the play. Now all following plays have a new host '127.0.0.1' in their inventory.

Steps To Reproduce:

I reduced it to being something with add_host and local_action and made a small playbook without roles to reproduce the issue.

---
- hosts: all
  become: no
  gather_facts: no

  tasks:
  - add_host: name={{ inventory_hostname }} group="new"
  - local_action: ping
  - ping:

- hosts: all
  become: no
  gather_facts: no

  tasks:
  - ping:

Expected Results:

Host 127.0.0.1 should not be added to inventory of chained plays.

Actual Results:

Host 127.0.0.1 is added to inventory list.

Output from playbook

$ ansible-playbook playbooks/bug.yml -i "192.168.1.1,"

PLAY [all] ******************************************************************** 

TASK: [add_host name={{ inventory_hostname }} group="new"] ******************** 
ok: [192.168.1.1]

TASK: [ping] ****************************************************************** 
ok: [192.168.1.1 -> 127.0.0.1]

TASK: [ping ] ***************************************************************** 
ok: [192.168.1.1]

PLAY [all] ******************************************************************** 

TASK: [ping ] ***************************************************************** 
ok: [127.0.0.1]
ok: [192.168.1.1]

PLAY RECAP ******************************************************************** 
192.168.1.1                : ok=4    changed=0    unreachable=0    failed=0   
127.0.0.1                  : ok=1    changed=0    unreachable=0    failed=0   

[jimi-c]

HI @c0rner, I just tested this on devel and it does not occur:

# ansible-playbook -vv test.yml -i 192.168.122.100,
Using /etc/ansible/ansible.cfg as config file
2 plays in test.yml
PLAY ***************************************************************************
TASK [add_host group=new name={{ inventory_hostname }}] ************************
changed: [192.168.122.100] => {"add_host": {"groups": ["new"], "host_name": "192.168.122.100", "host_vars": {"group": "new"}}, "changed": true}
TASK [ping] ********************************************************************
ok: [192.168.122.100] => {"changed": false, "ping": "pong"}
TASK [ping] ********************************************************************
ok: [192.168.122.100] => {"changed": false, "ping": "pong"}
PLAY ***************************************************************************
TASK [ping] ********************************************************************
ok: [192.168.122.100] => {"changed": false, "ping": "pong"}
PLAY RECAP *********************************************************************
192.168.122.100            : ok=4    changed=1    unreachable=0    failed=0   

I verified (after noticing in the above output) that the local_action: ping is in fact hitting the localhost, so that is something minor we need to clean up.

Normally we close bugs once they're verified as fixed on devel, however we'll hold this open for now to see if it's something we want to backport/fix in the 1.9.x branch.

Thanks!

[mgarstecki]

Encountering the same problem here, on Ansible 1.9.4.
It has lead to a few hacks in our playbooks, since sometimes we actually want to run actions on localhost, so we can't use a !localhost filter in our hosts statements.

[jimi-c]

@mgarstecki Yes, unfortunately the fix in devel is due to the rewrite there, and I don't believe there's anything we can backport to he 1.9.x branch, so this will only be fixed going forward for now.

[abadger]

We took another look at this in preparation for 1.9.5 and decided that this is an issue which has a high risk of regression if we try to fix it in 1.9 (due to not having an easy way to fix it in the 1.9 codebase and the code in 2.0 being very different). So this is one where we're going to have to say please upgrade to 2.x if this is an issue that you need to have fixed.