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 ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CACVha7dxFc9OOTTsqOsaT%3DQcBC6Nfu1UCmhStWkV645otSjOQg%40mail.gmail.com.
