I am trying to use the async option on an action running in a playbook, like so:
It seems that async mode doesn’t like the way you are specifying arguments in long form.
action: junos_install_os >
hostname=“{{ inventory_hostname }}”
version=“{{ IMAGE_TAGS[junos_image_tag].version }}”
package=“{{ IMAGE_TAGS[junos_image_tag].package }}”
package_dir=“{{ IMAGE_DIR }}”
reboot=True
Complex arguments were invented primarily for the needs of the cloudformation module, and since there are really no data structures
being passed around here it seems ok to just use regular key=value data.
I’ll make a github ticket about this so we might have time to fix it later, but it seems it only would block a few limited use cases, and yours is not, at least yet, one of them.
Ticket here: https://github.com/ansible/ansible/issues/3150
I do not anticipate this being closed for 1.2.
After changing to the syntax you proposed, I get the following error:
TASK: [Junos OS install, please wait, this could take a bit …] **************
failed: [vsrx_blue] => {“ansible_job_id”: “363705553608”, “changed”: false, “cmd”: “/home/jeremy/.ansible/tmp/ansible-1370804287.26-173733122300989/junos_install_os /home/jeremy/.ansible/tmp/ansible-1370804287.26-173733122300989/arguments”, “failed”: 1, “finished”: 1}
msg: [Errno 2] No such file or directory
<job 363705553608> FAILED on vsrx_blue
FATAL: all hosts have already failed – aborting
I appreciate any other suggestions, ideas you might have.
Thank you!
– Jeremy
Hard to say without being able to run this module in my environment, but it’s not a syntax issue most likely – though I’d like to see what you are passing to the module to tell for sure (paste your playbook task line? and then show the output from running the playbook from -v -v -v)
It looks like the async_wrapper code couldn’t find the status file it is used to writing, but adding some debugging inside async_wrapper might not hurt.
possibly useful – if you export ANSIBLE_KEEP_REMOTE_FILES=1 it will leave the files around on the remote system, and then you can execute the exact same command outside of the async code to see if you see any particular problems. I would be curious if it runs fine without async with the above approach on the remote system, when executed the same way.
I would also suggest poking around here:
https://github.com/ansible/ansible/blob/devel/library/internal/async_wrapper
and
https://github.com/ansible/ansible/blob/devel/library/internal/async_status
You will notice some commented out syslogging in async_wrapper that may provide a good facility for learning more about what is going on. You may want to add some more log lines, but any open() calls may be where you’re getting the exception.