Hey all,
I’m just trying out the ec2_lc stuff and it appears to be non-functioning. I tried the following:
- ec2_lc:
name=special
image_id=“ami-XXX”
key_name=default
security_groups=‘group,group2’
But I get this error:
TASK: [ec2_lc name=special image_id=“ami-XXX” key_name=default security_groups=‘group,group2’] ***
failed: [127.0.0.1] => {“failed”: true, “parsed”: false}
invalid output was: Traceback (most recent call last):
File “~/.ansible/tmp/ansible-tmp-1394808739.09-69351858807498/ec2_lc”, line 1477, in
main()
File “~/.ansible/tmp/ansible-tmp-1394808739.09-69351858807498/ec2_lc”, line 1473, in main
create_launch_config(connection, module)
File “~/.ansible/tmp/ansible-tmp-1394808739.09-69351858807498/ec2_lc”, line 1432, in create_launch_config
connection.create_launch_configuration(lc)
AttributeError: ‘NoneType’ object has no attribute ‘create_launch_configuration’
FATAL: all hosts have already failed – aborting
So I then tried it exactly as detailed here:
http://docs.ansible.com/ec2_lc_module.html
- ec2_lc: >
name: special
image_id: ami-XXX
key_name: default
security_groups: ‘group,group2’
And then I got this:
TASK: [ec2_lc name: special image_id: ami-XXX key_name: default security_groups: ‘group,group2’] ***
failed: [127.0.0.1] => {“failed”: true}
msg: this module requires key=value arguments ([‘name:’, ‘special’, ‘image_id:’, ‘ami-XXX’, ‘key_name:’, ‘default’, ‘security_groups:’, ‘group,group2’])
FATAL: all hosts have already failed – aborting
Am I doing something wrong or am i just the first person to be using this and its currently a non-functioning module?
Cheers!!
Tim
So the traceback needs to be better caught, I agree, and upgrades here would be welcome – this is a new module just added on the 1.6 development branch via pull request a few days ago.
The second problem is one of documentation, the “>” should not be there if using “colon” syntax for hash members. It instead passed a long string. I’ll take care of this now.
So when using Ansible, you can do this:
foo: x=1 y=2
or you can do:
foo:
x: 1
y: 2
when you say
foo: >
the “>” means "what follows is a string continued on the following lines, so that would be:
foo: >
x=1
y=2
It’s better to just do “option1” or “option 2” 
As such, I think the module just choked badly when given bad input in the first case, which is not ideal… but not so bad.
The second case it’s giving you a proper error message about the string being input.
Hey Michael,
Thanks for the response. Yeah, im looking to help out if i can. From what you wrote it sounds like the module is barfing on that specific input case, but you noted that input could be given like:
foo:
x: 1
y: 2
But when I do:
- name: aws | create launch configuration
ec2_lc:
name: test
image_id: “{{ ami_id }}”
key_name: “{{ keypair }}”
security_groups: “{{stack_name.stdout}}”
I get the trace error again. If im reading your note correctly, the configuration I have there should be valid, right?
The trace may be a thing.
Can you file a github ticket on that last one so we can see if we can reproduce it?
Thanks!
–Michael
I started debugging it and see that the connection instance is None, which is why I believe it explodes.
Will look into it some more, but I filed the ticket here:
https://github.com/ansible/ansible/issues/6495
Cheers
Ok I have found the issue (despite knowning no python at all).
Problem is that the boto.ec2.autoscale.connect_to_region function takes a single region as its argument, not a dict. I’ll try and whip up a pull request to fix the issue.
Cheers
Ok i’ve ‘fixed’ it.
The documentation says that the region is not required, but in my haste I had not specified it. Strikes me that region should be marked as required, or the error handler should pickup on the fact that no EC2_REGION env var is defined, and error out accordingly.
Thanks!