"So should I make a custom module which loops over nova_compute asynchronously, and also assigns floating IPs?"
I'd first rather know where the openstack API allows simultaneous creation of N virtual machines of the same image type. I expect the floating IP stuff is fast and a usual with_items loop isn't a problem there, once those guests exist. (Using neutron, I assume?) On Fri, Jul 11, 2014 at 6:54 PM, Kurt Yoder <[email protected]> wrote: > So should I make a custom module which loops over nova_compute > asynchronously, and also assigns floating IPs? > > Would such a module be useful to the wider community, or is it too > specialized to contribute back? > > On Friday, July 11, 2014 6:34:47 PM UTC-4, Michael DeHaan wrote: > >> So some of the provisioning modules, like AWS in particular, support >> spinning up "N" modules at a time by passing "count" or "exact_count". >> >> Rackspace I believe does this with manual looping (for now), but I could >> be wrong and that might have just been historical truth. >> >> If the OpenStack API says we can launch 10 at once, it could be made to >> do similar things. >> >> >> >> >> On Fri, Jul 11, 2014 at 5:28 PM, Kurt Yoder <[email protected]> >> wrote: >> >>> I guess that error is because I put a "with_items" in there. >>> >>> How does everyone else do this? I don't understand how to loop >>> asynchronously. See pseudo-code: >>> >>> < start all 5 at once: > >>> < start up openstack host > >>> < assign it a floating ip > >>> < capture the floating ip > >>> < end when all 5 have a floating ip > >>> < wait for all 5 floating IPs to have an open SSH port > >>> >>> On Friday, July 11, 2014 5:20:34 PM UTC-4, Kurt Yoder wrote: >>>> >>>> Well, "async" is totally a bust. I got a message: >>>> >>>> fatal: [localhost] => lookup plugins (with_*) cannot be used with >>>> async tasks >>>> >>>> >>>> >>>> On Thursday, July 10, 2014 6:17:48 PM UTC-4, Kurt Yoder wrote: >>>>> >>>>> Hello list, >>>>> >>>>> I anticipate provisioning 10-20 VMs using Ansible, then assigning >>>>> floating IPs to each, then waiting for SSH to become available for each >>>>> VM. >>>>> I would like to do this in parallel instead of serially. Specifically: >>>>> >>>>> >>>>> - Start the VMs, but don't block >>>>> - Assign the IPs, but don't block >>>>> - Wait on SSH until all VMs respond >>>>> >>>>> >>>>> I saw the nova_compute "wait: 'no'" option, but when I use it I get a >>>>> stack trace: >>>>> >>>>> failed: [localhost] => (item=1) => {"failed": true, "item": 1, >>>>>> "parsed": false} >>>>>> invalid output was: Traceback (most recent call last): >>>>>> File >>>>>> "/home/ubuntu/.ansible/tmp/ansible-tmp-1405028178.0-234314980043958/nova_compute", >>>>>> line 1490, in <module> >>>>>> main() >>>>>> File >>>>>> "/home/ubuntu/.ansible/tmp/ansible-tmp-1405028178.0-234314980043958/nova_compute", >>>>>> line 266, in main >>>>>> _create_server(module, nova) >>>>>> File >>>>>> "/home/ubuntu/.ansible/tmp/ansible-tmp-1405028178.0-234314980043958/nova_compute", >>>>>> line 194, in _create_server >>>>>> private = [ x['addr'] for x in getattr(server, >>>>>> 'addresses').itervalues().next() if x['OS-EXT-IPS:type'] == 'fixed'] >>>>>> StopIteration >>>>>> >>>>> >>>>> Perhaps I'm using it incorrectly: >>>>> >>>>> - name: Launch cluster VM on Openstack >>>>>> nova_compute: >>>>>> name: "{{ os_username }}_cluster1" >>>>>> state: present >>>>>> login_username: "{{ os_username }}" >>>>>> login_tenant_name: "{{ os_tenant }}" >>>>>> login_password: "{{ os_password }}" >>>>>> image_id: "{{ os_image_id }}" >>>>>> key_name: "{{ os_username }}_controller_key" >>>>>> wait: "no" >>>>>> flavor_id: "{{ os_flavor_id }}" >>>>>> auth_url: "{{ os_url }}" >>>>>> user_data: "#cloud-config\nmanage_etc_hosts: true" >>>>>> >>>>> >>>>> >>>>> So, two questions: >>>>> >>>>> >>>>> 1. Am I using "wait" correctly? >>>>> 2. Should I use "wait" to get to my desired parallel VM launch, as >>>>> described above, or should I use something else, e.g. "async"? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> -Kurt >>>>> >>>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/ansible-project/32b58cdf-17cd-42c9-8ef6- >>> dc90327e989a%40googlegroups.com >>> <https://groups.google.com/d/msgid/ansible-project/32b58cdf-17cd-42c9-8ef6-dc90327e989a%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/2326c06a-dec5-43b2-bd22-bb6856d14227%40googlegroups.com > <https://groups.google.com/d/msgid/ansible-project/2326c06a-dec5-43b2-bd22-bb6856d14227%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxLVusfWzA2RurR%2BzA2QJ2AB1AtD0V-qV6BAoEE%2BZeGHw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
