Skip to content
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

fix precedence issue with facts #32302

Merged
merged 1 commit into from
Nov 1, 2017
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 3 additions & 1 deletion docs/docsite/rst/playbooks_variables.rst
Original file line number Diff line number Diff line change
Expand Up @@ -865,7 +865,7 @@ In 2.x, we have made the order of precedence more specific (with the last listed
* inventory file or script host vars [2]_
* inventory host_vars/*
* playbook host_vars/*
* host facts
* host facts / cached set_facts [3]_
* play vars
* play vars_prompt
* play vars_files
Expand All @@ -884,6 +884,8 @@ Basically, anything that goes into "role defaults" (the defaults folder inside t

.. [1] Tasks in each role will see their own role's defaults. Tasks defined outside of a role will see the last role's defaults.
.. [2] Variables defined in inventory file or provided by dynamic inventory.
.. [3] When created with set_facts's cacheable option, variables will have the high precedence in the play,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be multiple levels?

  • host facts
  • variables created with cacheable set_facts in a previous play when read from the cache
    <..>
  • variables created with set_facts in current play

Is there anything else to distinguish the precendence of host_facts and 'cached set_facts'?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, they update the same dict, it is order in which they were set, but not by their nature

but will be the same as a host facts precedence when they come from the cache.

.. note:: Within any section, redefining a var will overwrite the previous instance.
If multiple groups have the same variable, the last one loaded wins.
Expand Down
2 changes: 1 addition & 1 deletion lib/ansible/plugins/action/set_fact.py
Original file line number Diff line number Diff line change
Expand Up @@ -54,5 +54,5 @@ def run(self, tmp=None, task_vars=None):

result['changed'] = False
result['ansible_facts'] = facts
result['ansible_facts_cacheable'] = cacheable
result['_ansible_facts_cacheable'] = cacheable
return result
9 changes: 4 additions & 5 deletions lib/ansible/plugins/strategy/__init__.py
Original file line number Diff line number Diff line change
Expand Up @@ -511,13 +511,12 @@ def parent_handler_match(target_handler, handler_name):
for target_host in host_list:
self._variable_manager.set_host_variable(target_host, var_name, var_value)
else:
cacheable = result_item.pop('ansible_facts_cacheable', True)
cacheable = result_item.pop('_ansible_facts_cacheable', False)
for target_host in host_list:
if cacheable:
if not original_task.action == 'set_fact' or cacheable:
self._variable_manager.set_host_facts(target_host, result_item['ansible_facts'].copy())

# If we are setting a fact, it should populate non_persistent_facts as well
self._variable_manager.set_nonpersistent_facts(target_host, result_item['ansible_facts'].copy())
if original_task.action == 'set_fact':
self._variable_manager.set_nonpersistent_facts(target_host, result_item['ansible_facts'].copy())

if 'ansible_stats' in result_item and 'data' in result_item['ansible_stats'] and result_item['ansible_stats']['data']:

Expand Down