While upgrading ansible we run into a deprecation warning:
[DEPRECATION WARNING]: DEFAULT_GATHER_TIMEOUT option, the
module_defaults keyword is a more generic version and can apply to all
calls to the M(ansible.builtin.gather_facts) or
M(ansible.builtin.setup) actions, use module_defaults instead. This
feature will be removed from ansible-core in version 2.18. Deprecation
warnings can be disabled by setting deprecation_warnings=False in
ansible.cfg.
"Set the timeout in seconds for the implicit fact gathering, see the
module documentation for specifics. It does not apply to user defined
ansible_collections.ansible.builtin.setup_module tasks."
Set the timeout in seconds for the implicit fact gathering, see the module documentation for specifics. It does not apply to user defined ansible_collections.ansible.builtin.setup_module tasks.
I think there’s a historical wart here. When a playbook contains “gather_facts: true”, it calls the gather_facts module. This in turn calls the setup module to accomplish the fact gathering. In that case only, and only if DEFAULT_GATHER_TIMEOUT is set, it will invoke the setup module with, effectively, “timeout: ‘{{ DEFAULT_GATHER_TIMEOUT }}’”.
The last line I quoted above means that if you, somewhere in your tasks, call the setup module, it won’t use DEFAULT_GATHER_TIMEOUT, and if you don’t include a “timeout:” yourself, in that case the setup module’s default of 10 seconds will be used rather than whatever value DEFAULT_GATHER_TIMEOUT may be set to.
ansible-config dump shows the default value for DEFAULT_GATHER_TIMEOUT is None – it’s undefined, and in fact will soon be going away. When you don’t set it, and nothing else sets the timeout for the setup module, that module uses its 10 second default.
Sadly, there is not a simple answer, this setting has always been
overloaded for 2 uses:
- total time a 'subfact' gathering will take: system, local,
networking, etc, though this list is never clear to the user .. or
really in the code.
- total time a particular fact (really only disk/device related ones)
is allowed to take before we abandon the effort. This is mostly to
deal with very slow or buggy network mounts (/me stares at NFS).
Also this didn't actually work for a long well in the code as the
facts module_utils just hardcoded it's own version with it's own
defaults which were not always in sync.Eventually this was fixed
(except the default being 10).
In the meantime 'gather_facts' became an action plugin vs being
hardcoded to be the 'setup.py' module, with some logic that makes it
'smart', specifically for networking appliances but also user
customizable (i use a 'mini_setup' + service_facts for example). So
the timeout didn't make as much sense as it was created specifically
thinking of 'setup.py', hence the deprecation as a config item.
In the future of 'fact gathering' we are mulling over several things,
the main one is splitting 'setup.py' into several dozen modules and
making 'gather_facts' even smarter depending on OS/distro targeted. We
also want to define more specific timeouts, like 'hardware' facts
(which check for the devices/mounts/disks as I mentioned above) and
'per plugin' timeouts. These will have much clearer language vs the
now deprecated 'default_gather_timeout'.