I spoke with other Ansible Core devs to get some clarity on this change.
This is not a change that is being made quickly, lightly, or without a whole of
bunch of reservation. In fact, that PR created by agaffney may not be merged
any time soon. He just wanted to get something started and there is still
ongoing discussion on that PR. It is definitely a WIP at this point.
The main reason for this change is that pretty much all of the Ansible CVEs to
date came from "fact injection", meaning a fact that contains executable Python
code Jinja will merrily exec(). Vars, hostvars, and facts are different in
Ansible (yes, this is confusing — sorry). All vars go through a templating
step. By copying facts to vars, it means facts get templated controller side
which could lead to controller compromise if malicious code exists in facts.
We created an AnsibleUnsafe class to protect against this, but stopping the
practice of injecting facts into vars would close the door completely. It also
alleviates some name collisions if you set a hostvar that has the same name as
a var. We have some methods that filter out certain variables, but keeping
facts and vars in separate spaces is much cleaner.
This also does not change how hostvars set via set_fact are referenced.
(set_fact should really be called set_host_var). Variables set with set_fact
are not facts and are therefore not inside the ansible_facts dict. They are in
the hostvars dict, which you can reference as {{ my_var }} or {{
hostvars['some-host']['my_var'] }} if you need to look it up from a different
host.
All that being said, the setting to control this behavior as Emilien pointed
out is inject_facts_as_vars, which defaults to True and will remain that way
for the foreseeable future. I would not rush into changing all the fact
references in playbooks. It can be a gradual process.
Setting inject_facts_as_vars to True means ansible_hostname becomes
ansible_facts.hostname. You do not have to use the hostvars dictionary — that
is for looking up facts about hosts other than the current host.
If you wanted to be proactive, you could start using the ansible_facts
dictionary today since it is compatible with the default setting and will not
affect others trying to use playbooks that reference ansible_facts.
In other words, with the default setting of True, you can use either
ansible_hostname or ansible_facts.hostname. Changing it to False means only
ansible_facts.hostname is defined.
> Like, really. I know we can't really have a word about that kind of decision,
> but... damn, WHY ?!
That is most certainly not the case. Ansible is developed in the open and we
encourage community members to attend meetings
<https://github.com/ansible/community/blob/master/meetings/README.md> and add
topics to the agenda <https://github.com/ansible/community/issues/325> for
discussion. Ansible also goes through a proposal process for major changes,
which you can view here
<https://github.com/ansible/proposals/issues?utf8=%E2%9C%93&q=is:issue+is:open>.
You can always go to #ansible-devel on Freenode or start a discussion on the
mailing list <https://groups.google.com/forum/#!forum/ansible-devel> to speak
with the Ansible Core devs about these things as well.
---
Respectfully,
Sam Doran
Senior Software Engineer
Ansible by Red Hat
sdo...@redhat.com <mailto:sdo...@redhat.com>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
