grains.has_key() always returns false in 2016.3.0

[knuta]

Description of Issue/Question

grains.has_key() always returns false in 2016.3.0

Setup

Our config has used constructs like {% if grains.has_key('os_family') and grains['os_family'] == 'Debian' %} for grains which are not present on all architectures. On 2016.3.0, this stopped working, but "grains.os_family is defined" still works.

Example SLS snippet for testing:

/tmp/graintest:
  file.managed:
    - contents: |
{% if grains.has_key('os_family') %}
        grains.has_key works
{% else %}
        grains.has_key doesn't work
{% endif %}
{% if grains.os_family is defined %}
        "is defined" works
{% else %}
        "is defined" doesn't work
{% endif %}

The resulting file (with empty lines removed) is:

grains.has_key doesn't work
"is defined" works

Steps to Reproduce Issue

Just run state.highstate with the SLS snipet above and look in /tmp/graintest.

Versions Report

skrotnisse:~# salt-call --versions-report
Salt Version:
Salt: 2016.3.0

Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: 1.5
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
Jinja2: 2.6
libgit2: Not Installed
libnacl: Not Installed
M2Crypto: 0.21.1
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.3.0
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pygit2: Not Installed
Python: 2.7.3 (default, Mar 14 2014, 11:57:14)
python-gnupg: Not Installed
PyYAML: 3.10
PyZMQ: 13.1.0
RAET: Not Installed
smmap: Not Installed
timelib: Not Installed
Tornado: 4.2.1
ZMQ: 3.2.3

System Versions:
dist: debian 7.10
machine: i686
release: 3.2.0-4-686-pae
system: Linux
version: debian 7.10

My salt master is currently running 2015.5.3, but I do not think that is relevant in this case, since the jinja is rendered on the client side as far as I can tell.

[wwentland]

It should be pointed out that your master should always be upgraded first and that the version you have installed has an unfixed CVE (cf. https://security-tracker.debian.org/tracker/CVE-2016-3176).

I would recommend to upgrade the master as soon as possible. Not sure if this is actually related to the problem at hand.

[knuta]

I have since upgraded my master to 2016.3 (I was halfway through a sitewide upgrade when I found the bug), and the behavior is the same.

[wwentland]

Thank you for checking!

[cachedout]

This is all fixed up by #33651