On 06/12/14 02:42, Chris Hoffman wrote: > 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. >
For local actions, as well as for the local part of a synchronize task, Ansible should force the connection to local only if it has not been explicitly set by the user (by having set the 'ansible_connection' hostvar). However, this requires that the current implementation allows to determine whether an option's current value has been set explicitly by the user or set by code due to a default policy. I am not sure if that distinction is currently possible. > 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 > <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 > <mailto:ansible-project+unsubscr...@googlegroups.com>. > To post to this group, send email to ansible-project@googlegroups.com > <mailto: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 > <https://groups.google.com/d/msgid/ansible-project/40037225-2faa-493d-9df2-b738ccc72a6f%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/53999884.3090406%40yahoo.gr. For more options, visit https://groups.google.com/d/optout.
