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, hodg...@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/2c6db5de-dfc5-48ec-a933-55b54332432b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
