Replies: 2 comments
-
|
Beta Was this translation helpful? Give feedback.
-
Yeah I plan to add the action group in 1.5.0, but I couldn't remember core version was needed so thanks for that! I should have mentioned it in this issue but I typed it up in a rush. Original discussion is here: #156 (comment)
Haha I had the same idea (in the other thread), including the idea that it's possibly not a good idea! I have other thoughts on how to do that that are opt-in, like potentially a lookup plugin whose purpose is to provide values for module defaults, or maybe an inventory plugin that could be used for the same purpose so you could have finer-grained control over the values per group/host (this would set some known variable for each host that could be referenced in module defaults or module calls for example). |
Beta Was this translation helpful? Give feedback.
-
SUMMARY
We have very centralized options, and in plugins, we have built-in capability to set those options via environment variables, INI (
ansible.cfg
) settings, Ansible variables, etc. across all of the controller-side plugins.Modules however, do not use any of those values. This is at least partially intentional on the part of Ansible: modules execute on a target host, not on the controller.
So we have only the
module_defaults:
keyword to be able to set defaults for these, and don't currently have a way to (re)infer the values from the same place as plugins (env vars can be read explicitly when settingmodule_defaults
via theenv
lookup, ansible vars can just be used directly, but there's no way to get the INI config values). There is also no "ansible-wide" place to configure such defaults, so at minimum amodule_defaults
section is needed per play[book].We also must consider again that using controller-side values may not be correct. This is especially important for sensitive values, like using the env vars and sink files for tokens.
So this issue is an acknowledgement of the current situation and a place to discuss various ways of addressing it.
We should consider utility, ease of use, intuitiveness in solutions, but also ensure we're encouraging good practices and working within the Ansible ecosystem and its standards and practices, rather than against.
Beta Was this translation helpful? Give feedback.
All reactions