Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Use connection locking to protect against competing host key prompts #13344
We acquire the connection lock before executing ssh, and release it as
Unfortunately, we can only lock against other connections: there's no
This problem was the original motivation for PR #12276, but although
Submitted for v2 as requested in #13318
referenced this pull request
Nov 28, 2015
I really think Ansible should have a "display" lock too, even if it's used only for this feature. When running against 16- or 32- or 64-node clusters, you still have prompts being overrun by other output (i.e., not other prompts, but just the task output from hosts that you approved before). @jimi-c said something about it being possible to set up a shared lock in display before forking, but @bcoca had some objection/concern with doing it that way, which I unfortunately can't remember now.
A couple of issues, iirc. The first had to do with serialization of the locks, they did not work well inside the object so I moved it into the class.
The second has to do with certain things failing when using the class level lock, I noticed this when i initially set this up for the debug printing, I have not had time to trace this (since it only affectes debug) but it seems to be related to multiprocess, stdout cloning and the lock 'global'.
The conflict noted by Github is because stable-2.0 doesn't include the pipelining change from #13200, while devel does. Since this was under consideration for inclusion in stable-2.0, I'm leaving this alone. Anyway, the conflict is trivial to resolve by hand.