At the moment my code is bound up in a playbook that I can't share. Sorry.

On Sunday, July 20, 2014 8:03:05 PM UTC-4, Bob Tiernay wrote:
>
> Hey Kurt,
>
> Do you happen to have a full example in a repo somewhere? I would be very 
> interested to check it out.
>
> Thanks in advance,
>
> Bob
>
> On Thursday, 17 July 2014 10:19:40 UTC-4, Kurt Yoder wrote:
>>
>> I forgot to include a critical piece of this solution. Here's how you 
>> invoke the task to tell Openstack to start the VMs:
>> - name: Create cluster
>>   hosts: os_api
>>   gather_facts: no
>>   roles: [instantiate] # "instantiate" is a role that includes the 
>> Openstack startup task
>>
>>
>> Perhaps this kind of example should be included in docs for parallel 
>> execution in Ansible. Let me know if you want me to help with that.
>>
>> -Kurt
>>
>> On Thursday, July 17, 2014 10:04:14 AM UTC-4, Kurt Yoder wrote:
>>>
>>> I found a different approach to this problem. 
>>>
>>>
>>> First create a cluster configuration file.
>>> $ cat cluster.yml
>>> ---
>>> cluster:
>>>   - cluster1
>>>   - cluster2
>>>
>>>
>>> Define the first task: setting up one connection to localhost for each 
>>> API call. 
>>> - include_vars: cluster.yml
>>>  
>>> - add_host:
>>>     name: "os_api_{{ item }}"
>>>     ansible_ssh_host: 127.0.0.1
>>>     groups: os_api
>>>     ansible_connection: local
>>>     oshost: "{{ item }}"
>>>   with_items: cluster
>>>
>>> Define a follow-on task: tell Openstack to start up the VMs.
>>> - name: Show host name
>>>   debug:
>>>     msg: "API connection: os_api_{{ oshost }}; Openstack host: {{ oshost 
>>> }}"
>>>
>>> - name: Launch cluster VM on Openstack
>>>   nova_compute:
>>>     name: "{{ os_username }}_{{ oshost }}"
>>>     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_for: 200
>>>     flavor_id: "{{ os_flavor_id }}"
>>>     auth_url: "{{ os_url }}"
>>>         user_data: "#cloud-config\nmanage_etc_hosts: true"
>>>
>>> - name: Assign IP address to cluster VM
>>>   quantum_floating_ip:
>>>     state: present
>>>     login_username: "{{ os_username }}"
>>>     login_password: "{{ os_password }}"
>>>     login_tenant_name: "{{ os_tenant }}"
>>>     network_name: "{{ os_network_name }}"
>>>     instance_name: "{{ os_username }}_{{ oshost }}"
>>>     internal_network_name: "{{ os_internal_network_name }}"
>>>     auth_url: "{{ os_url }}"
>>>   register: quantum_info
>>>
>>> - name: Wait for cluster SSH to become available
>>>   wait_for:
>>>     port: 22
>>>     host: "{{ quantum_info.public_ip }}"
>>>     timeout: 180
>>>     state: started
>>>
>>>
>>>
>>> This method gives the following benefits:
>>>
>>>    - I can define lots of flavors and images in my cluster.yml 
>>>    definition.
>>>    - I can launch them all in parallel using Ansible's built-in, robust 
>>>    parallel execution. 
>>>    - I have access to all of Ansible's primitives while doing so, so I 
>>>    can build in *any* custom logic.
>>>    - No need to add options to nova_compute.
>>>
>>>
>>> Overall, I'm extremely happy with this solution. To reiterate: *no code 
>>> changes are required*!
>>>
>>>
>>>
>>> On Wednesday, July 16, 2014 5:02:31 PM UTC-4, Michael DeHaan wrote:
>>>>
>>>> Additions of new params to add IP spawning behavior would be reasonable.
>>>>
>>>> (assign_public_ip, True/False, etc)
>>>>
>>>> What might you prefer on names?
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jul 15, 2014 at 1:27 PM, Kurt Yoder <kyo...@data-tactics.com> 
>>>> wrote:
>>>>
>>>>> I dug a bit further. The API does allow min_count and max_count, much 
>>>>> the way boto does for AWS. 
>>>>>
>>>>> When you submit a request with min_count, your instances are named 
>>>>> <ansible-provide name>-<instance UUID>. That's acceptable, though not 
>>>>> ideal.
>>>>>
>>>>> I'm taking a look at the Ansible ec2 module, and the code for boto 
>>>>> instance-launching code looks very different than the nova_compute 
>>>>> instance-launching code. I haven't run it yet; I need to dig around to 
>>>>> find 
>>>>> my ec2 creds so I can run a test.
>>>>>
>>>>> The Ansible ec2 module also allows one to assign public IPs while 
>>>>> launching multiple instances. The Ansible nova_compute module does not 
>>>>> permit this ATM.
>>>>>
>>>>>
>>>>> On Friday, July 11, 2014 9:50:10 PM UTC-4, Michael DeHaan wrote:
>>>>>
>>>>>> "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 <kyo...@data-tactics.com> 
>>>>>> 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 <
>>>>>>>> kyo...@data-tactics.com> 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 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/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 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/
>>>>>>> 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 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/2949ac2a-e83e-4074-bc26-02652b90e605%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/ansible-project/2949ac2a-e83e-4074-bc26-02652b90e605%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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/fcc599ca-c151-45aa-820b-910e13e1e4de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to