salt: grains: jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'os' when rendering Pillar

Description Having just upgraded to 3002.2, we are seeing random instances where Pillar fails to render due to core grains (specifically ‘os’) not being defined.

Exception in master log is as follows:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 260, in render_tmpl
    output = render_str(tmplstr, context, tmplpath)
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 505, in render_jinja_tmpl
    raise SaltRenderError("Jinja variable {}{}".format(exc, out), buf=tmplstr)
salt.exceptions.SaltRenderError: Jinja variable 'dict object' has no attribute 'os'
2020-12-29 19:08:01,847 [salt.pillar      :888 ][CRITICAL][3653] Rendering SLS 'global.os_defaults' failed, render error:
Jinja variable 'dict object' has no attribute 'os'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 498, in render_jinja_tmpl
    output = template.render(**decoded_context)
  File "/usr/lib/python3/dist-packages/jinja2/asyncsupport.py", line 76, in render
    return original_render(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in render
    return self.environment.handle_exception(exc_info, True)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise
    raise value.with_traceback(tb)
  File "<template>", line 1, in top-level template code
jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'os'

Setup The Pillar SLS being rendered which fails with the above is quite straightforward:

$ cat pillar/global/os_defaults.sls 
{% if grains['os'] == 'MacOS' %}
homedirbase: '/Users'
roothomedir: '/var/root'
{% elif grains['os'] == 'Ubuntu' %}
homedirbase: '/home'
roothomedir: '/root'
{% endif %}

Steps to Reproduce the behavior Unfortunately I’ve not found how to reliably reproduce this. We have a few hundred minions, and following the upgrade (we were previously at 2017.7.8) we’re observing this at random (i.e. most of the time, rendering happens correctly, but when it doesn’t, forcing a saltutil.refresh_grains + saltutil.refresh_pillar does the trick, but the problem can crop up again after an indeterminate amount of time).

I can attest that the ‘os’ grain is the only grain that’s failing to be defined, and this is only observed for MacOS minions.

Expected behavior grains[‘os’] to reliably evaluate within Pillar SLS definitions

Versions Report

salt --versions-report

master:

Salt Version:
          Salt: 3002.2
 
Dependency Versions:
          cffi: Not Installed
      cherrypy: Not Installed
      dateutil: 2.6.1
     docker-py: 2.5.1
         gitdb: 2.0.3
     gitpython: 2.1.8
        Jinja2: 2.10
       libgit2: Not Installed
      M2Crypto: Not Installed
          Mako: Not Installed
       msgpack: 0.5.6
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: Not Installed
      pycrypto: 2.6.1
  pycryptodome: 3.4.7
        pygit2: Not Installed
        Python: 3.6.9 (default, Jul 17 2020, 12:50:27)
  python-gnupg: 0.4.1
        PyYAML: 3.12
         PyZMQ: 17.1.2
         smmap: 2.0.3
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.2.5
 
System Versions:
          dist: ubuntu 18.04 Bionic Beaver
        locale: UTF-8
       machine: x86_64
       release: 4.15.0-112-generic
        system: Linux
       version: Ubuntu 18.04 Bionic Beaver

minions:

Salt Version:
          Salt: 3002.2
 
Dependency Versions:
          cffi: 1.12.2
      cherrypy: unknown
      dateutil: 2.8.0
     docker-py: Not Installed
         gitdb: 2.0.6
     gitpython: 2.1.15
        Jinja2: 2.10.1
       libgit2: Not Installed
      M2Crypto: Not Installed
          Mako: 1.0.7
       msgpack: 1.0.0
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     pycparser: 2.19
      pycrypto: Not Installed
  pycryptodome: 3.9.8
        pygit2: Not Installed
        Python: 3.7.4 (default, Nov 16 2020, 16:27:58)
  python-gnupg: 0.4.4
        PyYAML: 5.3.1
         PyZMQ: 18.0.1
         smmap: 3.0.2
       timelib: 0.2.4
       Tornado: 4.5.3
           ZMQ: 4.3.1
 
System Versions:
          dist: darwin 19.6.0 
        locale: UTF-8
       machine: x86_64
       release: 19.6.0
        system: Darwin
       version: 10.15.7 x86_64

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Comments: 28 (9 by maintainers)

Most upvoted comments

Hello, could anybody fix this bug please? Because of this we cannot install the critical security patches provided by 3002.6