Issue 1:
ISSUE TYPE

Bug Report

COMPONENT NAME

group module

ANSIBLE VERSION

1.9

SUMMARY

Hi,

the group module seems to not work right. I am using centos 7. The expected result is that it wouldn't fail since the group is properly present. The group was added by ´yum install docker´

Task:

- group: name=dockerroot state=present gid=989

Sample

TASK: [newrelic | Configure New Relic Sysmond] ********************************
changed: [192.168.0.244]

TASK: [newrelic | group name=dockerroot state=present gid=989] ****************
failed: [192.168.0.244] => {"failed": true, "name": "dockerroot"}
msg: groupmod: GID '989' already exists

FATAL: all hosts have already failed -- aborting

PLAY RECAP ********************************************************************
to retry, use: --limit @/root/vmbuilder.retry

192.168.0.244 : ok=73 changed=17 unreachable=0 failed=1

[root@172-17-42-1 ~]# ansible-playbook --version
ansible-playbook 1.9.0.1
configured module search path = None
[root@172-17-42-1 ~]# grep -i "989" /etc/group
dockerroot:x:989:newrelic

Issue 2:
ISSUE TYPE

Bug Report

COMPONENT NAME

ec2

ANSIBLE VERSION

ansible 2.4.0.0
config file = /etc/ansible/ansible.cfg
configured module search path = [u'/Users/rpm/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
ansible python module location = /Users/rpm/sandbox/venv-ansible-2.4.0/lib/python2.7/site-packages/ansible
executable location = /Users/rpm/sandbox/venv-ansible-2.4.0/bin/ansible
python version = 2.7.13 (default, Dec 18 2016, 07:03:39) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)]

CONFIGURATION

All defaults

OS / ENVIRONMENT

Issue not platform specific

SUMMARY

The count_tag parameter on the ec2 module should maintain the exact_count number of ec2 instances which match the supplied tags, wherever these ec2 instances are found within the account and region. This was the behavior until version 2.4.

As of version 2.4, the behavior changed, so that the match is no longer on 'count_tag' alone (as documented), but also on the vpc_subnet_id. Any instances with matching tags but in different subnets (even within the same VPC) are no longer counted as matching, and new instances are created.

This is a serious bug for people maintaining EC2 infrastructure.

STEPS TO REPRODUCE

Create instance, like so:

---

- hosts: localhost
vars:
subnet_id: subnet-1111111
tasks:
- ec2:
count_tag:
Name: duplicate-test-1
Department: FooBar
Application: Baz
exact_count: 1
group_id: sg-000000
image: ami-3bdd502c
instance_tags:
Name: duplicate-test-1
Department: FooBar
Application: Baz
instance_type: t2.nano
key_name: some.key.name
region: us-east-1
vpc_subnet_id: "{{ subnet_id }}"

Later, re-run playbook but use different subnet ID:

---

- hosts: localhost
vars:
subnet_id: subnet-2222222
tasks:
- ec2:
count_tag:
Name: duplicate-test-1
Department: FooBar
Application: Baz
exact_count: 1
group_id: sg-000000
image: ami-3bdd502c
instance_tags:
Name: duplicate-test-1
Department: FooBar
Application: Baz
instance_type: t2.nano
key_name: some.key.name
region: us-east-1
vpc_subnet_id: "{{ subnet_id }}"

EXPECTED RESULTS

The count_tags and exact_count parameter should be respected, based on tags alone, and the running instance created in the first playbook run should be recognized as matching those parameters during the second playbook run.

ACTUAL RESULTS

As of version 2.4, the running instance with matching tags is no longer counted because it is in a different subnet, and a redundant instance is created.

COMMENTS

This behavior change was introduced without documentation, and is very problematic - the point of using count_tags and exact_count is to be able to maintain an instance or set of instances based on a tagging strategy - subnets may change over time, and often multiple instances will be distributed across subnets for resiliency. Silently including the subnet as an additional criterion for tag matching doesn't make a lot of sense, and breaks the expected behavior.

If matching on tags + subnet is actually useful to someone, it would make more sense to make it an explicit parameter (although at that point, offering matching on VPCs, or instance types, or AMIs, or various other attributes which are not currently matched on should maybe come into consideration... and personally I feel that if that's necessary, then one's EC2 tagging strategy needs a revisit).