config options templatable

[bcoca]

if plugin has templar available, use it to handle config options
todo: make sure most plugins (where it makes sense) have appropriate templar setup

fixes #49946, #73268, #58281

alt for #58288

ISSUE TYPE

• Bugfix Pull Request
• Feature Pull Request

COMPONENT NAME

config manager/plugins

[felixfontein]

The CI failures show a problem with this approach: there are some config parameters that look like (parts of) templates, but should not be evaluated. Examples are the variable_start_string and variable_end_string parameters of the template lookup (which is where CI fails). It could also be that there is a lookup plugin which expects a template string as an input that is then templated with some extra variables provided by the lookup - when that template is evaluated before its original value reaches the plugin, the result could be completely wrong, or templating could fail due to missing variables.

[bcoca]

@felixfontein added protection for 'non templates', as for the evaluation, this should only affect get_option calls, in general the lookups should only be trying to template the _terms that are passed in as non keyed input. Still, i'll look to see if there are any that look to template other terms and find a way to mark options as 'static' or not.

[felixfontein]

@felixfontein added protection for 'non templates', as for the evaluation, this should only affect get_option calls, in general the lookups should only be trying to template the _terms that are passed in as non keyed input. Still, i'll look to see if there are any that look to template other terms and find a way to mark options as 'static' or not.

One interesting place are probably inventory plugins, these sometimes already explicitly template some of the options (to allow using lookups to be used for credentials, for example). In c.g the proxmox and linode inventories do that, and in community.dns and community.hrobot also have code for handling that.

[bcoca]

yes, but many of those 'templatable fields' do not require {{ }} which would then not pass the is_temlpate test , for the others that do their own templating I'll have to look at options as i mentioned above, since inventory options is one of the ones we specifically want to enable.

[bcoca]

checked proxmox, it uses is_template so the only issue is reusing proxmox_url setting as a variable, which can still be done by having the plugin set_option + update self._templar variables or as it currently works, silently failing at the configmanager and letting the templar at proxmox do the work. The linnode one is even simpler.

[bcoca]

Thinking about a new property: template: static|vault|restricted|full|implicit:

• static: no templating (default if we want strict backwards compat)
• vault: only unvault
• restricted: (the proposed default) template but no lookups (how constructed keywords currently work)
• full: template normally (alt default?) (works like loop:)
• implicit: 'always template, assume {{ }}' (works like when:)

note: that plugin field should always be static, the auto plugin normally evaluates this

[ansibot]

The test ansible-test sanity --test pep8 [explain] failed with 1 error:

lib/ansible/config/manager.py:563:17: E125: continuation line with same indent as next logical line

click here for bot help