Open Stack

On Thu, Jul 26, 2018 at 1:48 AM Cédric Jeanneret <cjeanner at 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
> > sdoran at redhat.com <mailto:sdoran at redhat.com>
> >
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev