The module subsystem alone is not (and pretty much cannot safely) be made resilient to modules that interrupt the network connection.
That said, all the bits and pieces are there to do what you need if you're doing custom work, but you'd have to string them together yourself to make an action/module pair that can be resilient to changes that interrupt the network connection. Take a look at the way the win_reboot action <https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/action/win_reboot.py> works- you can follow a similar pattern yourself: write a custom action plugin (and stuff it in action_plugins/ next to your playbook). The action plugin can exec the module, catch the network failure, poke at the box until it responds again, then ensure the changes were made correctly. There are several different approaches to doing this that work, depending on how exactly correct you want to be about races, failures that look like successes, etc, but the naive "happy path" case is very simple to implement. Or you could just wait for async. :) On Sunday, June 19, 2016 at 5:15:49 PM UTC-7, Rahul Garg wrote: > > Hi Matt, > > You mention the async support is going to be put in 2.2. Is there any > other workaround for this problem other than the win_scheduled_task module. > For example, can we use polling/pinging to see whether the connection is > back up? > > I have tried several methods but none seem to work, > http://pastebin.com/PS82PnBF is what I came up with but even this freezes > after installation. > > Appreciate any help/advice. > > > On Tuesday, 3 May 2016 11:10:37 UTC-7, Matt Davis wrote: >> >> Depending on what you're trying to do, doing it as a scheduled >> task/script might make sense in the interim (eg, see >> http://docs.ansible.com/ansible/win_scheduled_task_module.html) >> >> On Tuesday, May 3, 2016 at 11:09:12 AM UTC-7, Matt Davis wrote: >>> >>> SSH seems to be very tolerant of momentary connection losses, so long as >>> the connection isn't actually "refused". >>> >>> WinRM under the covers is a very different beast (HTTP-based, logical >>> connection instead of a single fixed TCP connection). It might be possible >>> to retry certain parts of the WinRM exchange, but in general it's not safe >>> to blanket retry requests (eg, you don't want to accidentally run something >>> twice). The problem case is where a connectivity change like that happens >>> before we receive the HTTP response from the Command/Send actions (retrying >>> Receive would probably be OK). >>> >>> The "right" way to deal with this would probably be to use async, but >>> that didn't make it in for Windows for 2.1 (should be in 2.2). Async >>> *should* be tolerant of most kinds of dodgy/unstable connections... >>> >>> >>> On Tuesday, May 3, 2016 at 10:52:09 AM UTC-7, hod...@gmail.com wrote: >>>> >>>> I am running Windows modules that disrupt the network connection. For >>>> instance, the installation of a network driver or the creation of a >>>> Network >>>> Team. The IP address doesn't change, and the network connection is only >>>> out >>>> for a few moments. But when these run, my Ansible playbook basically >>>> freezes - it just sits there running the task until Ansible times out and >>>> the playbook fails. My colleagues tell me Linux handles this gracefully, >>>> reconnecting and continuing when the connection is back up. Any idea how I >>>> can get this behavior with Windows? >>>> >>> -- 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/1c701022-e94c-4213-b5a6-297433a07149%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
