ansible 1.6: ec2_lc does not function?

[Timothy Perrett]

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 <module>

    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

[Michael DeHaan]

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.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/c0829985-6a14-4fa1-b8ee-1a9cdbb326e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael DeHaan]

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.

[Timothy Perrett]

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? 

[Michael DeHaan]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/e8f8c67b-0b4c-4966-9bc7-eee578589843%40googlegroups.com.

[Timothy Perrett]

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

[Timothy Perrett]

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

[Timothy Perrett]

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!

[Michael DeHaan]

Replied on the ticket here:  https://github.com/ansible/ansible/issues/6495

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/d098fe5b-673c-49ec-b633-b6aa2d82a8cd%40googlegroups.com.