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'. I hope this helps. -- ---------- Brian Coca (he/him/yo) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CACVha7dxFc9OOTTsqOsaT%3DQcBC6Nfu1UCmhStWkV645otSjOQg%40mail.gmail.com.
