-
Notifications
You must be signed in to change notification settings - Fork 199
Can't gather facts when running seperate Task. #109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi Max,
Can you include the output of "ansible --version", the OS you're on and
the OS of the target machine. This seems to work for me locally.
…On Wed, Mar 07, 2018 at 03:52:45AM -0800, maxhenze wrote:
TASK [_gather_facts : Gather facts]
******************************************************************************
11:59:24 I p=29093 u=root | : TASK [_gather_facts : Gather facts]
******************************************************************************
fatal: [tbi_client01]: FAILED! => {"changed": false, "msg": "Unsupported
parameters for (setup) module: _ansible_shell_executable Supported parameters
include: fact_path,filter,gather_subset,gather_timeout"}
11:59:24 E p=29093 u=root | : fatal: [tbi_client01]: FAILED! => {"changed":
false, "msg": "Unsupported parameters for (setup) module:
_ansible_shell_executable Supported parameters include:
fact_path,filter,gather_subset,gather_timeout"}
task looks like this:
• name: Gather facts
action: setup
while gather_facts: no is set in my playbook
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Ok, I can see some interesting stuff in the log I didn't notice when reading via e-mail. It looks like it might be passing too many variables into setup. Let me have a play |
Target: Machine running ansible: ansible --version |
Can you share the command line you used to run it? Any ansible*_executable variables are handled specially by the modules, but there is another code path where they aren't, but I can't figure out how it gets triggered :) |
Since ansible can't handle ssh-keys from variables yet i had to come up with some sort of work around for my problem. Playbook: test.yml
Role testing:
Role _decrypt_ssh_key:
While in my host_vars:
is set ANSIBLE_STRATEGY=mitogen ansible-playbook playbooks/test.yml |
also - i pressed the wrong button while commenting |
At what point does the setup module get called in this structure? Is it from within another role? |
Whoops, now I understand :) |
I'm going to have to read the code line-by-line later to figure this out, I've reproduced your playbook structure and cannot trigger the problem with your exact version of Ansible. We're still missing something. Do you have anything magical in ansible.cfg? |
ok - i stripped down my config to only use your strategy plugin + directory informations
from what i get the module_args get lost as soon as i m running with mitogen, when mitogen is not enabled default module_args are passed to the setup task: fatal: [tbi_client01]: FAILED! => { w/o mitogen: |
Also i noticed theses beauties: any correlation? these appear as soon as the first task is called |
Could it be that some empty dict magically gets populated from somewhere invisible?
Hi Max,
The most recent GitHub should not log those messages any more.
Thanks so much for hunting down the module_args hint, this is amazingly
helpful.
I just pushed one quick change that /might/ help, where Mitogen did
something subtly different and would have discarded some objects it should
keep. I don't think it'll fix your problem, but might be worth a retry just
in case
…On 7 March 2018 at 20:04, maxhenze ***@***.***> wrote:
Also i noticed theses beauties:
15:17:10 W mitogen: get_module_source('time'): cannot find source
15:17:10 W mitogen: get_module_source('operator'): cannot find source
15:17:10 W mitogen: get_module_source('_locale'): cannot find source
15:17:10 W mitogen: get_module_source('grp'): cannot find source
15:17:10 W mitogen: get_module_source('datetime'): cannot find source
15:17:10 W mitogen: get_module_source('syslog'): cannot find source
15:17:10 W mitogen: get_module_source('itertools'): cannot find source
15:17:10 W mitogen: get_module_source('select'): cannot find source
15:17:10 W mitogen: get_module_source('_random'): cannot find source
15:17:10 W mitogen: get_module_source('binascii'): cannot find source
15:17:10 W mitogen: get_module_source('math'): cannot find source
15:17:10 W mitogen: get_module_source('fcntl'): cannot find source
15:17:10 W mitogen: get_module_source('cStringIO'): cannot find source
15:17:10 W mitogen: get_module_source('cPickle'): cannot find source
15:17:10 W mitogen: get_module_source('_collections'): cannot find source
15:17:10 W mitogen: get_module_source('zlib'): cannot find source
15:17:10 W mitogen: get_module_source('bz2'): cannot find source
15:17:10 W mitogen: get_module_source('_hashlib'): cannot find source
15:17:10 W mitogen: get_module_source('_json'): cannot find source
15:17:10 W mitogen: get_module_source('_io'): cannot find source
15:17:10 W mitogen: get_module_source('strop'): cannot find source
15:17:10 W mitogen: get_module_source('_functools'): cannot find source
15:17:10 W mitogen: get_module_source('_heapq'): cannot find source
15:17:10 W mitogen: get_module_source('_struct'): cannot find source
any correlation?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#109 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAJCy7ZNfGtyTntLrSPXGQDNsFYvYAIks5tb-xrgaJpZM4SgUSF>
.
|
Would it be possible for you to run the non-Mitogen case with
ANSIBLE_KEEP_REMOTE_FILES=1, then find the run of setup.py in the target
host's ~/.ansible/tmp, zip that whole dir up and send it to me?
Ansible's argument handling rules are a bit "fluid", there was quite some
guesswork involved in the initial implementation work
…On 7 March 2018 at 20:06, David Wilson ***@***.***> wrote:
Hi Max,
The most recent GitHub should not log those messages any more.
Thanks so much for hunting down the module_args hint, this is amazingly
helpful.
I just pushed one quick change that /might/ help, where Mitogen did
something subtly different and would have discarded some objects it should
keep. I don't think it'll fix your problem, but might be worth a retry just
in case
On 7 March 2018 at 20:04, maxhenze ***@***.***> wrote:
> Also i noticed theses beauties:
> 15:17:10 W mitogen: get_module_source('time'): cannot find source
> 15:17:10 W mitogen: get_module_source('operator'): cannot find source
> 15:17:10 W mitogen: get_module_source('_locale'): cannot find source
> 15:17:10 W mitogen: get_module_source('grp'): cannot find source
> 15:17:10 W mitogen: get_module_source('datetime'): cannot find source
> 15:17:10 W mitogen: get_module_source('syslog'): cannot find source
> 15:17:10 W mitogen: get_module_source('itertools'): cannot find source
> 15:17:10 W mitogen: get_module_source('select'): cannot find source
> 15:17:10 W mitogen: get_module_source('_random'): cannot find source
> 15:17:10 W mitogen: get_module_source('binascii'): cannot find source
> 15:17:10 W mitogen: get_module_source('math'): cannot find source
> 15:17:10 W mitogen: get_module_source('fcntl'): cannot find source
> 15:17:10 W mitogen: get_module_source('cStringIO'): cannot find source
> 15:17:10 W mitogen: get_module_source('cPickle'): cannot find source
> 15:17:10 W mitogen: get_module_source('_collections'): cannot find source
> 15:17:10 W mitogen: get_module_source('zlib'): cannot find source
> 15:17:10 W mitogen: get_module_source('bz2'): cannot find source
> 15:17:10 W mitogen: get_module_source('_hashlib'): cannot find source
> 15:17:10 W mitogen: get_module_source('_json'): cannot find source
> 15:17:10 W mitogen: get_module_source('_io'): cannot find source
> 15:17:10 W mitogen: get_module_source('strop'): cannot find source
> 15:17:10 W mitogen: get_module_source('_functools'): cannot find source
> 15:17:10 W mitogen: get_module_source('_heapq'): cannot find source
> 15:17:10 W mitogen: get_module_source('_struct'): cannot find source
>
> any correlation?
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#109 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AAAJCy7ZNfGtyTntLrSPXGQDNsFYvYAIks5tb-xrgaJpZM4SgUSF>
> .
>
|
newest version didn't fix the problem, but i tried several things and got something quite interesting:
with this:
and suddenly module_args appeared:
|
Hey, is it definitely that exact step in your playbook that triggers the setup module? Some actions sometimes internally trigger it on demand. Does the part where the failure occurs definitely have the name of the task where you run setup appearing above it as the title? |
Since module "setup" is even directly mentioned and i dont have any other steps in my stripped down playbook - I'm quite sure. If you have any idea how to get more in depth data i'd be glad to have a deeper look into it.
|
I had not even thought of that! If you pull the latest extension and run with "-vvvv", this will produce extreme logging, the part that would be useful is any line mentioning call_async(... run_module .. setup ) Sorry, a little overworked the past 2 days ;) |
well - thats funny - newest version won't let me reproduce... did you solve by accident? :D
|
I fixed a bunch of important bugs yesterday, but I can't see how it could possibly be related! Grmbl. This is actually a worse outcome than finally finding whatever was causing your issue :) Yesterday I fixed
And then a9c6c13 .. did your target machine have Ansible installed on it? That might somehow be an explanation |
can confirm ansible on target machine |
Ahah! Yes, and I bet the version of Ansible on the target was slightly younger than the one on the host :) You can keep Ansible on the target machine now, it's no problem, that's fully protected against since yesterday. Feel free to close this bug. I'm happy we've found the culprit :) /cc #114 |
since i m able to run the whole of my playbook by now - i m thrilled to close this issue :) i will report as soon as i dig up something new |
Just one final note.. I am always interested in more timing information.. latency of network, CPUs of target boxes, how much playbook time is spent in big apt-gets and suchlike, and finally before/after of /usr/bin/time output. Thanks again |
This is just from my Playbook doing nothing since nothing as changed. - Will update with Full Playbook runtime.
|
Not exactly spectacular, but not bad either :) Is this on a low latency network? |
it is - both machines currently run on a dedicated switch - also i do a lot of package installation with this - and zypper isn't particularly fast when it comes to repo communication - so i guess thats what killing the time improvements. |
Could it be that some empty dict magically gets populated from somewhere invisible?
Python at some point (at least since https://bugs.python.org/issue14605) began populating sys.meta_path with its internal importer classes, meaning that interpreters no longer start with an empty sys.meta_path.
change google agent number
TASK [_gather_facts : Gather facts] ******************************************************************************
11:59:24 I p=29093 u=root | : TASK [_gather_facts : Gather facts] ******************************************************************************
fatal: [tbi_client01]: FAILED! => {"changed": false, "msg": "Unsupported parameters for (setup) module: _ansible_shell_executable Supported parameters include: fact_path,filter,gather_subset,gather_timeout"}
11:59:24 E p=29093 u=root | : fatal: [tbi_client01]: FAILED! => {"changed": false, "msg": "Unsupported parameters for (setup) module: _ansible_shell_executable Supported parameters include: fact_path,filter,gather_subset,gather_timeout"}
task looks like this:
action: setup
while gather_facts: no is set in my playbook
The text was updated successfully, but these errors were encountered: