ec2.results is not being defined

ansible ver=2.0.2

When I’m registering the ec2 var isn’t results suppose to be automatically defined as the results of what was registered in the variable. I’m getting this when trying to debug the ec2.results var:
TASK [debug ec2 var] ***********************************************************
Monday 23 May 2016 11:14:18 -0500 (0:00:38.587) 0:00:43.306 ************
ok: [aaa-frs-ans-test1] => {
“ec2.results”: “VARIABLE IS NOT DEFINED!”
}
ok: [aaa-frs-ans-test2] => {
“ec2.results”: “VARIABLE IS NOT DEFINED!”
}
Here’s my creation task:

  • hosts: ec2_instances
    connection: local
    gather_facts: true
    tasks:
  • name: Launch Instance
    ec2:
    group_id: “{{ hostvars[inventory_hostname].group_id }}”
    instance_type: ‘t2.micro’
    image: “{{ hostvars[inventory_hostname].image }}”
    wait: true
    region: ‘us-east-1’
    keypair: ‘QA_KEYPAIR’
    vpc_subnet_id: “{{ subnet }}”
    instance_tags: “{{ hostvars[inventory_hostname].tags }}”
    register: ec2

They launch fine and if I debug ec2.instances I get all the info from that variable. Also when I debug just ec2 I get all the info as well. I did see though that when I debug just ec2 there isn’t a .results section but again I thought that was a default var.

Why don't you debug the var itself and look what subelements there are?

As to why there is no results subelement I have no clue...

Johannes

I did that and there isn’t the results element. I’ve seen a lot of people using that, so not sure why its not being set.

does anyone know or have a clue why ec2.results wouldn’t be populated?

I think what you want is ec2.instances instead of ec2.results.

You will likely only have the results sub key if you are also using something like with_items or with_subelements. See http://docs.ansible.com/ansible/playbooks_loops.html#using-register-with-a-loop for an explanation of register + looping, where it creates a results key.

does anyone know or have a clue why ec2.results wouldn't be populated?

Random shots in the dark:

- Is 'ec2' as a variable name clashing with the module name in some way?
  What if you do 'register: foo' instead?

- What *is* in 'foo', if you 'debug: var=foo' it? Is it everything you'd
  expect to see *except* the 'results' element, or something totally different?

Actually, backing up a step: What do you expect to see in the results
element, and why? Is the information that you're looking for somewhere
else in the variable?

                                      -Josh (jbs@care.com)

(apologies for the automatic corporate disclaimer that follows)

This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.

i also registered ec2_info as a var just to play around and it has the same results but it does display: sorry for the long output
ok: [aaa-frs-ans-test3] => {
“ec2_info”: {
“changed”: true,
“instance_ids”: [
“i-790418fe”
],
“instances”: [
{
“ami_launch_index”: “0”,
“architecture”: “x86_64”,
“block_device_mapping”: {
“/dev/sda1”: {
“delete_on_termination”: true,
“status”: “attached”,
“volume_id”: “vol-0c034fa7”
}
},
“dns_name”: “”,
“ebs_optimized”: false,
“groups”: {
“sg-7c538d04”: “fsr-allow-all”
},
“hypervisor”: “xen”,
“id”: “i-790418fe”,
“image_id”: “ami-3683605b”,
“instance_type”: “t2.micro”,
“kernel”: null,
“key_name”: “FSR_DEV_QA_KEYPAIR”,
“launch_time”: “2016-05-24T18:13:10.000Z”,
“placement”: “us-east-1a”,
“private_dns_name”: “ip-10-196-135-193.ec2.internal”,
“private_ip”: “10.196.135.193”,
“public_dns_name”: “”,
“public_ip”: null,
“ramdisk”: null,
“region”: “us-east-1”,
“root_device_name”: “/dev/sda1”,
“root_device_type”: “ebs”,
“state”: “running”,
“state_code”: 16,
“tags”: {
“Env”: “Dev”,
“Name”: “aaa-fsr-ans-test2”
},
“tenancy”: “default”,
“virtualization_type”: “hvm”
}
],
“tagged_instances”:
}
}
for each of the hosts, meaning 3 hosts.

Matt that makes sense. I did try ec2.instances but it is only add the first host not all three. I did do a debug on ec2 and ec2.instances and it is showing all 3 instances that I’m turning up. Any ideas on that. This is only happening on the add_hosts module. I have a wait for ssh to come up task and ec2.instances var are giving me an ok for all three.

I did try ec2.instances but it is only add the first host not all
three. I did do a debug on ec2 and ec2.instances and it is showing all
3 instances that I'm turning up. Any ideas on that. This is only
happening on the add_hosts module. I have a wait for ssh to come up
task and ec2.instances var are giving me an ok for all three.

I tried with this trivial playbook, and it worked fine:

  - hosts: localhost
    vars:
      myhosts: [apple, banana, cherry]
    tasks:
      - debug: var=myhosts
      - add_host: name={{ item }} groups=mygroup
        with_items: myhosts
      - debug: var=groups['mygroup']

I got

  TASK: [debug var=groups['mygroup']]