Possible bug in 1.9.2 ec2

I have the following task:

`

  • name: Create ELK instance
    ec2:
    image: “{{ubuntu_image.ami}}”
    region: “{{ec2_region}}”
    vpc_subnet_id: “{{env_subnets.private|for_count(item)}}”
    instance_type: “{{elk_instance_type}}”
    assign_public_ip: false
    group: “{{security_groups}}”
    instance_tags:
    Name: “{{env_prefix}}elk-{{item}}”
    elk: “group”
    env: “{{env}}”
    managed_by: ansible
    exact_count: 1
    count_tag:
    Name: “{{env_prefix}}elk-{{item}}”
    key_name: “{{aws_key_name}}”
    wait: yes
    register: ec2_elk
    with_sequence: count={{elk_instance_count}}
    `

elk_instance_count = 1, and all the other attributes have correct values.

When I run this task the instance to be started is already running and the task should be “ok, changed=false” with the ec2_elk register populated.

With 1.9.1, this is indeed what happens. With 1.9.2-rc2 the status is “skipped” and the ec2_elk register is not populated.

To help me better debug, does anybody know of a reason why this behavior should have changed?

this might be a bug, i fixed several issues with the sequence lookup
in 1.9.2, confirmed that i see what you raised, i did not test for a
count of 1, I'll add that to the basic tests.

This remains in 1.9.2

-barry

And it doesn’t matter if the instance already exists. Even when trying to create new instance the task is skipped. (Which makes sense – a skip is a skip.)

Looks like it a bug with count=1

`

  • name: count=2
    debug: var=item
    with_sequence: count=2

  • name: count=1
    debug: var=item
    with_sequence: count=1

`

`
TASK: [count=2] ***************************************************************
ok: [localhost] => (item=1) => {
“item”: “1”,
“var”: {
“item”: “1”
}
}
ok: [localhost] => (item=2) => {
“item”: “2”,
“var”: {
“item”: “2”
}
}

TASK: [count=1] ***************************************************************
skipping: [localhost]
`

(I tried other numbers > 1 and they all seem to work)

https://github.com/ansible/ansible/issues/11422

this should be fixed in current devel and in possible future 1.9.3 release