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
>     <[email protected] <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 [email protected]
>         <javascript:>.
>         To post to this group, send email to
>         [email protected] <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 [email protected]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> 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 [email protected].
To post to this group, send email to [email protected].
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.

Reply via email to