-
Notifications
You must be signed in to change notification settings - Fork 23.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add variable evaluation notes to docs #39302
Conversation
Signed-off-by: Adam Miller <admiller@redhat.com>
@@ -0,0 +1,30 @@ | |||
.. _variable_evaluation: | |||
|
|||
Variable Evaluation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My impression is that this topic is more about the lazy evaluation of templates rather than variables
In general, Ansible evaluates any variables in playbook content at the last | ||
possible second, which means that if you define a data structure that data | ||
structure itself can define variable values within it, and everything “just | ||
works” as you would expect. This also means variable strings can include other |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree with the phrase "just works" as you would expect
: it is subjective and does not illuminate the actual behaviour. In my case, the fact that lazy evaluation is used came as a complete surprise.
b: 3 | ||
|
||
|
||
When using an Ansible :ref:`Lookup Plugin`, do note that the value will be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This paragraph seems to conflate at least two important points which may merit separate paragraphs:
- lazy template evaluation has the knock-on effect that lookup plugins may be executed more than once, take care if these are not idempotent or if they have side effects
- set_fact is a mechanism by which you can "fix" template evaluation at a point in time
var with the result of the Lookup Plugin be stored in the variable, effectively | ||
resulting in a single evaluation of the variable. | ||
|
||
:: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be useful to define more precisely the point(s) at which template evaluation is carried out, perhaps e.g. "templates passed in as arguments to module invocations are fully evaluated at the point of invocation" (which is why set_fact "fixes" template values)
The test
The test
|
Signed-off-by: Adam Miller <admiller@redhat.com>
The test
|
Signed-off-by: Adam Miller <admiller@redhat.com>
ping @bcoca - would you mind responding to the comments from @jim-minter, I don't think I know the vars code well enough to properly answer a couple of the outlying questions. |
|
||
When using an Ansible :ref:`Lookup Plugin`, do note that the value will be | ||
evaluated every time the variable is expanded in a template or in a playbook | ||
unless it is explicitly used with ``set_fact`` which will evaluate and define |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dont put set_fact here, explain below that how it works as it is a task option
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry but I don't follow ... what do you mean "how it works as it is a task option"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
friendly nag: ping @bcoca
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that 'set_fact' is not magic onto itself, the reason it works is because module options are evaluated
Signed-off-by: Adam Miller admiller@redhat.com
SUMMARY
Docs update to explain variable evaluation
ISSUE TYPE
COMPONENT NAME
docs
ANSIBLE VERSION