On Thu, Jul 26, 2018 at 1:48 AM Cédric Jeanneret <cjean...@redhat.com> wrote: > > Hello Sam, > > Thanks for the clarifications. > > On 07/25/2018 07:46 PM, Sam Doran wrote: > > 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. > > so if, for convenience, we do this: > vars: > a_mounts: "{{ hostvars[inventory_hostname].ansible_facts.mounts }}" > > That's completely acceptable and correct, and won't create any security > issue, right? > > > > > 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 toTrue 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/#%21forum/ansible-devel> to speak with > > the Ansible Core devs about these things as well. > > And I also have the "Because" linked to my "why" :). big thanks!
Do we have a plan for which Ansible version might be the default in upcoming TripleO versions? If this is the thread to discuss it then, I want to point out that TripleO's been using ceph-ansible for Ceph integration on the client and server side since Pike and that ceph-ansible 3.1 (which TripleO master currently uses) fails on Ansible 2.6 and that this won't be addressed until ceph-ansible 3.2. John > > Bests, > > C. > > > > > --- > > > > 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 > > > > -- > Cédric Jeanneret > Software Engineer > DFG:DF > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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