We're using a turing complete programming language. It's possible. Just needs to be done.
On Thu, Jun 12, 2014 at 8:09 AM, 'Petros Moisiadis' via Ansible Project < [email protected]> wrote: > 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]> >> 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]. >>> 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/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 [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/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 > <https://groups.google.com/d/msgid/ansible-project/53999884.3090406%40yahoo.gr?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/CA%2BnsWgwu-kxMSCW7FgV%3DpG5ES3szGgzFGzrhcQ7yUGegt4OsBQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
