Ok, well I did track down the issue into the delegate code in the core runner. By forcing the transport to local, this resolved the issue. It appears all the delegate logic deals with hostvars to make the determination on transport to use. I spent some time digging into the action plugin and couldn't figure out if you can override hostvars there or if that would have other residual effects. This also could be an issue with the core runner since I believe when you delegate to localhost that it should force a local transport.
One thing I forgot to note was the synchronize plugin worked great when working with vagrant. In that case, the connection was properly set to local when running the synchronize plugin. Since vagrant runs on localhost, maybe the fuzzy logic worked correctly here. I'll see if I can dig in some more but the override in the inventory did the trick in my case which presumably is due to the transport in hostvars being properly set. On Wednesday, June 11, 2014 6:40:10 PM UTC-4, Michael DeHaan wrote: > > No, we don't add documentation in this project when the software can be > made to do the right thing. If localhost needs to know to use the local > connection here, this can be dealt with amid the various fuzzy logic > already in the synchronize plugin. > > > > > On Wed, Jun 11, 2014 at 11:08 AM, Chris Hoffman <christoph...@gmail.com > <javascript:>> wrote: > >> I just ran into this same issue. As alluded to above, adding this line >> to my inventory resolved the issue. >> >> localhost ansible_connection=local >> >> In my case, I was passing an explicit user and private-key on the command >> line which were not set up on my machine. Should there be a note added to >> this module about the situation of trying to SSH to the local machine? I >> like how this module is trying to hide some of the complexity of it >> actually being a local command run but delegated to localhost but this >> ended up being a difficult thing to troubleshoot. >> >> >> On Wednesday, May 14, 2014 2:37:48 AM UTC-4, Ernest0x wrote: >>> >>> On 05/13/2014 10:49 PM, Michael DeHaan wrote: >>> >>> It depends if localhost is in inventory or not, but there is nothing to >>> presume an explicit entry of localhost has requested a particular way to >>> connect. >>> >>> But it is indeed presumed to connect through ssh, probably because this >>> is the default for all hosts with undefined ansible_connection/connection. >>> So, I am thinking that perhaps it would be better default behavior to make >>> a sensible exception for localhost and choose 'local' connection (when >>> 'ansible_connection' is undefined and 'connection' in the playbook not set). >>> >> -- >> 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 <javascript:>. >> To post to this group, send email to ansible...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/d2977dda-2781-4524-a643-54526af1f726%40googlegroups.com >> >> <https://groups.google.com/d/msgid/ansible-project/d2977dda-2781-4524-a643-54526af1f726%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/40037225-2faa-493d-9df2-b738ccc72a6f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
