state.sls fails to render state with pillar data: Jinja variable 'dict object' has no attribute #29028

kevins9 · 2015-11-19T01:28:01Z

This is only occurring on my minions running Salt 2015.5.5 and CentOS 7. Issue is similar to #16727 and #16656.

Version info - master and minion

[root@master ~]# cat /etc/redhat-release
CentOS release 6.5 (Final)
[root@master ~]# salt --versions
           Salt: 2015.5.3
         Python: 2.6.6 (r266:84292, Jan 22 2014, 09:42:36)
         Jinja2: 2.7.3
       M2Crypto: 0.20.2
 msgpack-python: 0.1.13
   msgpack-pure: Not Installed
       pycrypto: 2.0.1
        libnacl: Not Installed
         PyYAML: 3.10
          ioflo: Not Installed
          PyZMQ: 2.2.0.1
           RAET: Not Installed
            ZMQ: 3.2.4
           Mako: Not Installed
        Tornado: 2.2.1

[root@centos7test-01 ~]# cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
[root@centos7test-01 ~]# salt-call --versions
           Salt: 2015.5.5
         Python: 2.7.5 (default, Jun 24 2015, 00:41:19)
         Jinja2: 2.7.2
       M2Crypto: 0.21.1
 msgpack-python: 0.4.6
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
        libnacl: Not Installed
         PyYAML: 3.10
          ioflo: Not Installed
          PyZMQ: 14.3.1
           RAET: Not Installed
            ZMQ: 3.2.5
           Mako: 0.8.1
        Tornado: Not Installed
        timelib: Not Installed
       dateutil: 1.5

Pillar top.sls

base:
  'role:bugdemo':
    - match: grain
    - bugdemo

Pillar bugdemo.sls

bugdemo: problem

minion /etc/salt/grains

role: bugdemo

Master /srv/salt/dev/bugdemo.sls

/var/tmp/{{ pillar['bugdemo'] }}:
  file.exists:
    - name: /var/tmp/{{ pillar['bugdemo'] }}

(Note: master config has "dev" saltenv configured with root /srv/salt/dev)

Evidence

Pillar value is present:

[root@centos7test-01 ~]# salt-call pillar.get bugdemo
local:
    problem

State fails to render when calling state.sls:

[root@centos7test-01 ~]# salt-call state.sls bugdemo saltenv=dev test=True
[INFO    ] Loading fresh modules for state activity
[INFO    ] Fetching file from saltenv 'dev', ** skipped ** latest already in cache 'salt://bugdemo.sls'
[CRITICAL] Rendering SLS 'dev:bugdemo' failed: Jinja variable 'dict object' has no attribute 'bugdemo'
local:
    Data failed to compile:
----------
    Rendering SLS 'dev:bugdemo' failed: Jinja variable 'dict object' has no attribute 'bugdemo'

Yet oddly enough, state.show_sls works:

[root@centos7test-01 ~]# salt-call state.show_sls bugdemo saltenv=dev
[INFO    ] Loading fresh modules for state activity
[INFO    ] Fetching file from saltenv 'dev', ** skipped ** latest already in cache 'salt://bugdemo.sls'
local:
    ----------
    /var/tmp/problem:
        ----------
        __env__:
            dev
        __sls__:
            bugdemo
        file:
            |_
              ----------
              name:
                  /var/tmp/problem
            - exists
            |_
              ----------
              order:
                  10000

This works on another minion:

[root@centos6test-01 ~]# salt-call grains.get role
local:
    bugdemo
[root@centos6test-01 ~]# salt-call pillar.get bugdemo
local:
    problem
[root@centos6test-01 ~]# salt-call state.sls bugdemo saltenv=dev test=True
[INFO    ] Loading fresh modules for state activity
[INFO    ] Fetching file from saltenv 'dev', ** skipped ** latest already in cache 'salt://bugdemo.sls'
[INFO    ] Running state [/var/tmp/problem] at time 17:25:33.280407
[INFO    ] Executing state file.exists for /var/tmp/problem
[ERROR   ] Specified path /var/tmp/problem does not exist
[INFO    ] Completed state [/var/tmp/problem] at time 17:25:33.281307
local:
----------
          ID: /var/tmp/problem
    Function: file.exists
      Result: False
     Comment: Specified path /var/tmp/problem does not exist
     Started: 17:25:33.280407
    Duration: 0.9 ms
     Changes:

Summary
------------
Succeeded: 0
Failed:    1
------------
Total states run:     1

[root@centos6test-01 ~]# cat /etc/redhat-release
CentOS release 6.7 (Final)
[root@centos6test-01 ~]# salt-call --versions
           Salt: 2015.5.3
         Python: 2.6.6 (r266:84292, Jul 23 2015, 15:22:56)
         Jinja2: 2.2.1
       M2Crypto: 0.20.2
 msgpack-python: 0.4.6
   msgpack-pure: Not Installed
       pycrypto: 2.0.1
        libnacl: Not Installed
         PyYAML: 3.10
          ioflo: Not Installed
          PyZMQ: 14.3.1
           RAET: Not Installed
            ZMQ: 3.2.5
           Mako: Not Installed
        Tornado: Not Installed

The text was updated successfully, but these errors were encountered:

kevins9 · 2015-11-19T01:56:26Z

When rewriting the state to use salt['pillar.get']('bugdemo') references, as per recommended in documentation, things work differently:

bugdemo.sls

/var/tmp/{{ salt['pillar.get']('bugdemo') }}:
  file.exists:
    - name: /var/tmp/{{ salt['pillar.get']('bugdemo') }}

Works correctly on the good minion

[root@centos6test-01 ~]# salt-call pillar.get bugdemo
local:
    problem
[root@centos6test-01 ~]# salt-call state.sls bugdemo saltenv=dev test=True
[INFO    ] Loading fresh modules for state activity
[INFO    ] Fetching file from saltenv 'dev', ** skipped ** latest already in cache 'salt://bugdemo.sls'
[INFO    ] Running state [/var/tmp/problem] at time 17:55:50.406954
[INFO    ] Executing state file.exists for /var/tmp/problem
[ERROR   ] Specified path /var/tmp/problem does not exist
[INFO    ] Completed state [/var/tmp/problem] at time 17:55:50.407932
local:
----------
          ID: /var/tmp/problem
    Function: file.exists
      Result: False
     Comment: Specified path /var/tmp/problem does not exist
     Started: 17:55:50.406954
    Duration: 0.978 ms
     Changes:

Summary
------------
Succeeded: 0
Failed:    1
------------
Total states run:     1

Works incorrectly on the bad minion

[root@centos7test-01 ~]# salt-call pillar.get bugdemo
local:
    problem
[root@centos7test-01 ~]# salt-call state.sls bugdemo saltenv=dev test=True
[INFO    ] Loading fresh modules for state activity
[INFO    ] Fetching file from saltenv 'dev', ** skipped ** latest already in cache 'salt://bugdemo.sls'
[INFO    ] Running state [/var/tmp/] at time 17:53:38.463031
[INFO    ] Executing state file.exists for /var/tmp/
[INFO    ] Path /var/tmp/ exists
[INFO    ] Completed state [/var/tmp/] at time 17:53:38.463903
local:
----------
          ID: /var/tmp/
    Function: file.exists
      Result: True
     Comment: Path /var/tmp/ exists
     Started: 17:53:38.463031
    Duration: 0.872 ms
     Changes:

Summary
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1

It never filled in the value "problem" into the state.

jfindlay · 2015-11-19T17:19:12Z

@kevins9, thanks for the report. Is it possible for you to reproduce this on 2015.8.1?

kevins9 · 2015-11-19T21:00:58Z

I updated the minion to 2015.8.1, and the problem persists - the pillar value is undefined when running state.sls:

[root@centos7test-01 ~]# salt-call saltutil.sync_grains
[INFO    ] Loading fresh modules for state activity
[INFO    ] Fetching file from saltenv 'base', ** skipped ** latest already in cache u'salt://top.sls'
[ERROR   ] Template was specified incorrectly: False
[ERROR   ] Template was specified incorrectly: False
[INFO    ] Creating module dir '/var/cache/salt/minion/extmods/grains'
[INFO    ] Syncing grains for environment 'dev'
[INFO    ] Loading cache from salt://_grains, for dev)
[INFO    ] Caching directory u'_grains/' for environment 'dev'
local:

[root@centos7test-01 ~]# salt-call saltutil.refresh_pillar
local:
    True

[root@centos7test-01 ~]# salt-call state.clear_cache
local:
    - highstate.cache.p

[root@centos7test-01 ~]# salt-call state.sls bugdemo saltenv=dev test=True
[INFO    ] Loading fresh modules for state activity
[INFO    ] Fetching file from saltenv 'dev', ** skipped ** latest already in cache u'salt://bugdemo.sls'
[INFO    ] Running state [/var/tmp/] at time 12:57:08.802585
[INFO    ] Executing state file.exists for /var/tmp/
[INFO    ] Path /var/tmp/ exists
[INFO    ] Completed state [/var/tmp/] at time 12:57:08.803485
local:
----------
          ID: /var/tmp/
    Function: file.exists
      Result: True
     Comment: Path /var/tmp/ exists
     Started: 12:57:08.802585
    Duration: 0.9 ms
     Changes:

Summary for local
------------
Succeeded: 1
Failed:    0
------------
Total states run:     1
Total run time:   0.900 ms

[root@centos7test-01 ~]# salt-call pillar.get bugdemo
local:
    problem

[root@centos7test-01 ~]# salt-call state.show_sls bugdemo saltenv=dev
[INFO    ] Loading fresh modules for state activity
[INFO    ] Fetching file from saltenv 'dev', ** skipped ** latest already in cache u'salt://bugdemo.sls'
local:
    ----------
    /var/tmp/problem:
        ----------
        __env__:
            dev
        __sls__:
            bugdemo
        file:
            |_
              ----------
              name:
                  /var/tmp/problem
            - exists
            |_
              ----------
              order:
                  10000

[root@centos7test-01 ~]# salt-call --versions
Salt Version:
           Salt: 2015.8.1

Dependency Versions:
         Jinja2: 2.7.2
       M2Crypto: 0.21.1
           Mako: 0.8.1
         PyYAML: 3.10
          PyZMQ: 14.3.1
         Python: 2.7.5 (default, Jun 24 2015, 00:41:19)
           RAET: Not Installed
        Tornado: 4.2.1
            ZMQ: 3.2.5
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 1.5
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
        libnacl: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: 1.2.3
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
   python-gnupg: Not Installed
          smmap: Not Installed
        timelib: Not Installed

System Versions:
           dist: centos 7.1.1503 Core
        machine: x86_64
        release: 3.10.0-229.11.1.el7.x86_64
         system: CentOS Linux 7.1.1503 Core

The master is still running the same version as prior. I may be able to update that later today and test again.

jfindlay · 2015-11-19T21:18:59Z

Thanks for the extra info, @kevins9.

joberget · 2015-11-26T14:01:04Z

Any news on this issue? I am seeing the same problems here on 2015.8.1 on Ubuntu 14.04 LTS.

jfindlay · 2015-12-01T23:58:13Z

@joberget, not that I know of.

dennsi · 2015-12-04T12:46:37Z

I can confirm this issue on Debian 8.2 with the minion version 2015.8.3 and 2015.5.8 booth from http://repo.saltstack.com/apt/debian/8. It works with the Ubuntu packages 2015.5.3 on my debian system from:
http://ppa.launchpad.net/saltstack/salt/ubuntu

salt-minion --versions-report
                  Salt: 2015.5.3
                Python: 2.7.9 (default, Mar  1 2015, 12:57:24)
                Jinja2: 2.7.3
              M2Crypto: 0.21.1
        msgpack-python: 0.4.2
          msgpack-pure: Not Installed
              pycrypto: 2.6.1
               libnacl: Not Installed
                PyYAML: 3.11
                 ioflo: Not Installed
                 PyZMQ: 14.4.0
                  RAET: Not Installed
                   ZMQ: 4.0.5
                  Mako: 1.0.0
               Tornado: Not Installed
 Debian source package: 2015.5.3+ds-1trusty1

thegrmpf · 2015-12-04T15:32:22Z

same issue here with minion 2015.5.5 running on opensuse 13.2

kucerarichard · 2015-12-15T22:30:00Z

salt.sls_id fills in the pillar data and runs the individual ID. Overall SLS still doesn't run.
this works for example:
salt 'mysqldb.*' state.sls_id slave_status mysql saltenv=prod

this does not:
salt 'mysqldb.*' state.sls mysql saltenv=prod

master version: salt 2015.2.0-805-gadc9977 (Lithium)
minion version: salt-call 2015.5.5 (Lithium)

But the same thing happens on just the minion with salt-call. It's talking to master and master reports rendering the pillar data, but maybe in wrong format because of different version?

So should I upgrade master to match versions?

UPDATE 12/16/15: RESOLVED -- I just did a yum install of salt on the master and got the update, and the problem is fixed.

salt 2015.5.5 (Lithium)
Scientific Linux release 6.3 (Carbon)

kevins9 · 2015-12-16T19:56:48Z

Update: on kucerarichard's advice I tested master 2015.5.5 with minion 2015.5.5 (CentOS 7) and had success. I also tested master 2015.5.5 with minion 2015.8.1 (CentOS 7), since I still had that system available from an earlier test - and that works as well.

Unfortunately, it seems that both of these combinations are now experiencing #27792 any time my pillar YAML contains a sequence of mappings - that used to work before, and pass a YAML lint. I will soon add my findings to that issue instead, however.

rbjorklin · 2016-06-20T11:52:29Z

I'm seeing the same behavior on 2016.3.1. Strangely enough this was working Friday when I left work and it's broken today (Monday) without anyone doing any changes as far as I know.

Salt Version:
           Salt: 2016.3.1

Dependency Versions:
           cffi: 0.8.6
       cherrypy: 3.2.2
       dateutil: 1.5
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.7.2
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: 0.21.1
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.7
   mysql-python: Not Installed
      pycparser: 2.14
       pycrypto: 2.6.1
         pygit2: Not Installed
         Python: 2.7.5 (default, Nov 20 2015, 02:00:19)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 14.7.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.5

System Versions:
           dist: centos 7.2.1511 Core
        machine: x86_64
        release: 3.10.0-327.13.1.el7.x86_64
         system: Linux
        version: CentOS Linux 7.2.1511 Core

EDIT: Seeing this repeated in journalctl every time I run my orchestration state.
salt-master[9174]: [ERROR ] Exception occurred while handling stream: [Errno 0] Success

rbjorklin · 2016-06-20T20:27:56Z

This line throws the exception even though I can clearly see that my key is in decoded_context on the line above.
This is the exception I hit. Will try take another look tomorrow.

rbjorklin · 2016-06-21T09:21:56Z

Tried doing a yum erase on both the master and the minion and reinstalled with 2016.3.0 (used to work with this) but still not working. Any ideas where to keep looking?

EDIT: Not sure if this will help in pinning down the issue but here's the traceback after taking the line from my previous comment out of the try block:

Rendering SLS 'base:application.server' failed: Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/salt/utils/templates.py", line 178, in render_tmpl
    output = render_str(tmplstr, context, tmplpath)
  File "/usr/lib/python2.7/site-packages/salt/utils/templates.py", line 365, in render_jinja_tmpl
    output = template.render(**decoded_context)
  File "/usr/lib/python2.7/site-packages/jinja2/environment.py", line 969, in render
    return self.environment.handle_exception(exc_info, True)
  File "/usr/lib/python2.7/site-packages/jinja2/environment.py", line 742, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "<template>", line 27, in top-level template code
  File "/usr/lib/python2.7/site-packages/jinja2/environment.py", line 397, in getattr
    return getattr(obj, attribute)
UndefinedError: 'dict object' has no attribute 'clusterEnvironment'

EDIT2: Btw it would be nice to get the line number from File "<template>", line 27, in top-level template code back when a valid Jinja variable 'dict object' has no attribute error happens.

EDIT3: As @kevins9 mentions here where this is happening is a sequence of mappings. I.E. 'clusterEnvironment': [{'key1': 'value1'}, {'key2': 'value2'}]

EDIT4: This is insane. I downgraded to 2016.3.0 and tried again, still broken. Went out for lunch, now it's working again. WTF?

rbjorklin · 2016-07-13T05:41:00Z

This randomly resurfaced and is once again blocking deployment... This is nasty.

EDIT: Seems as if the machines have been upgraded during my vacation, back on 2016.3.1 again so that might be causing this. Anything relevant changed between 2016.3.0 and 2016.3.1?

EDIT2: Working in 2016.3.1. This time it might have been my doing...

hgfischer · 2017-07-10T16:25:15Z

Similar problem here on Ubuntu 14.04 LTS:

Salt Version:
           Salt: 2016.11.6
 
Dependency Versions:
           cffi: 0.8.2
       cherrypy: 2.3.0
       dateutil: 2.6.0
      docker-py: Not Installed
          gitdb: 0.5.4
      gitpython: 0.3.2 RC1
          ioflo: 1.3.8
         Jinja2: 2.7.2
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: 0.21.1
           Mako: 0.9.1
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: 1.2.3
      pycparser: 2.10
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.6 (default, Oct 26 2016, 20:30:19)
   python-gnupg: 0.3.6
         PyYAML: 3.10
          PyZMQ: 14.4.0
           RAET: Not Installed
          smmap: 0.8.2
        timelib: 0.2.4
        Tornado: 4.2.1
            ZMQ: 4.0.5
 
System Versions:
           dist: Ubuntu 14.04 trusty
        machine: x86_64
        release: 4.4.0-83-generic
         system: Linux
        version: Ubuntu 14.04 trusty

    Comment: An exception occurred in this state: Traceback (most recent call last):
                File "/usr/lib/python2.7/dist-packages/salt/state.py", line 1750, in call
                  **cdata['kwargs'])
                File "/usr/lib/python2.7/dist-packages/salt/loader.py", line 1705, in wrapper
                  return f(*args, **kwargs)
                File "/usr/lib/python2.7/dist-packages/salt/states/file.py", line 1821, in managed
                  **kwargs
                File "/usr/lib/python2.7/dist-packages/salt/modules/file.py", line 4342, in check_managed_changes
                  **kwargs)
                File "/usr/lib/python2.7/dist-packages/salt/modules/file.py", line 3836, in get_managed
                  **kwargs)
                File "/usr/lib/python2.7/dist-packages/salt/utils/templates.py", line 178, in render_tmpl
                  output = render_str(tmplstr, context, tmplpath)
                File "/usr/lib/python2.7/dist-packages/salt/utils/templates.py", line 386, in render_jinja_tmpl
                  buf=tmplstr)
              SaltRenderError: Jinja variable 'salt.utils.odict.OrderedDict object' has no attribute 'gw'
``

IliyanIliev1 · 2018-08-23T12:20:14Z

Hello All,
I have the same error , and no idea WHY
-----------------------------------------------error---------------------------------------------------------------------------------
ill.sofia.elex.be:
Data failed to compile:

Rendering SLS 'TEST:interfaces' failed: Jinja variable 'salt.pillar object' has no attribute 'sofia.elex.be'

~
-------------------------------------------------end--------------------------------------------------------------------------------

settings:
salt:
{% set config = pillar[grains['domain']]['interfaces']['conf_eth1'] %}
eth1_config_mainrouter:
network.managed:
- name: {{ config['name'] }}
- enabled: {{ config['enabled'] }}
- type: {{ config['type'] }}
- proto: {{ config['proto'] }}
- onboot: {{ config['onboot'] }}
- userctl: {{ config['userctl'] }}
- ipaddr: {{ config['ipaddr'] }}
- netmask: {{ config['netmask'] }}

pillar:

{%- if salt.config.get('pillarenv') == "TEST" %}
sofia.elex.be:
interfaces:
conf_eth1:
name: eth1
enabled: True
type: eth
proto: none
onboot: yes
userctl: no
ipaddr: 192.168.1.1
netmask: 255.255.255.0

     conf_eth2:
       name: eth2
       enabled: True
       type: eth
       proto: none
       onboot: yes
       userctl: no
       ipaddr: 172.16.1.2
       netmask: 255.255.255.0

{% endif %}

salt '*' config.get pillarenv
TEST

master and minion config:

root@ill salt]# egrep -v "#|^$" /etc/salt/master

file_roots:
TEST:
- /srv/salt/TEST
top_file_merging_strategy: same
pillar_roots:
base:
- /srv/pillar
TEST:
- /srv/pillar/TEST
log_file: /var/log/salt/master
log_level_logfile: debug
log_granular_levels:
'salt': 'info'
'salt.utils.job': 'debug'
'salt.master': 'debug'
[root@ill salt]#

[root@ill salt]# egrep -v "#|^$" /etc/salt/minion
master: ill.sofia.elex.be
environment: TEST
pillarenv: TEST
[root@ill salt]#

[root@ill interfaces]# salt-minion --versions-report
Salt Version:
Salt: 2017.7.7

Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: Not Installed
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
Jinja2: 2.7.2
libgit2: Not Installed
libnacl: Not Installed
M2Crypto: Not Installed
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.5.1
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: Not Installed
Python: 2.7.5 (default, Aug 4 2017, 00:39:18)
python-gnupg: Not Installed
PyYAML: 3.11
PyZMQ: 15.3.0
RAET: Not Installed
smmap: Not Installed
timelib: Not Installed
Tornado: 4.2.1
ZMQ: 4.1.4

System Versions:
dist: centos 7.4.1708 Core
locale: UTF-8
machine: x86_64
release: 3.10.0-693.el7.x86_64
system: Linux
version: CentOS Linux 7.4.1708 Core

[root@ill interfaces]# salt-master --versions-report
Salt Version:
Salt: 2017.7.7

Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: Not Installed
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
Jinja2: 2.7.2
libgit2: Not Installed
libnacl: Not Installed
M2Crypto: Not Installed
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.5.1
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: Not Installed
Python: 2.7.5 (default, Aug 4 2017, 00:39:18)
python-gnupg: Not Installed
PyYAML: 3.11
PyZMQ: 15.3.0
RAET: Not Installed
smmap: Not Installed
timelib: Not Installed
Tornado: 4.2.1
ZMQ: 4.1.4

System Versions:
dist: centos 7.4.1708 Core
locale: UTF-8
machine: x86_64
release: 3.10.0-693.el7.x86_64
system: Linux
version: CentOS Linux 7.4.1708 Core

[root@ill interfaces]#

rbjorklin · 2018-08-23T12:29:25Z

@IliyanIliev1 if your domain is sofia.elex.be this is the line causing you issues: {% set config = pillar[grains['domain']]['interfaces']['conf_eth1'] %}

Looks like you're trying to lookup an entry (sofia.elex.be) in the pillar dict and it's not in there.

Unrelated, I'm pretty sure this issue can be closed now as it's only full of user errors from what I can see.

sriramperumalla · 2020-08-19T18:28:02Z

Hi Team,
I too face same issue with salt master version 3000.3 running on centos 7.8 with salt windows minion running salt version 3001.1. Please find the error with salt versions below:
[pdmlink@saltmaster workers]$ sudo salt -C 'G@roles:worker' state.apply abc.workers.worker
Worker:
Data failed to compile:

Rendering SLS 'base:abc.workers.worker.deploy' failed: Jinja variable 'dict object' has no attribute 'workers'

ERROR: Minions returned with non-zero exit code
[pdmlink@saltmaster workers]$
[pdmlink@saltmaster workers]$ salt --version
salt 3000.3
[pdmlink@saltmaster workers]$ salt --versions
Salt Version:
Salt: 3000.3

Dependency Versions:
cffi: 1.6.0
cherrypy: Not Installed
dateutil: Not Installed
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
Jinja2: 2.7.2
libgit2: 0.26.3
M2Crypto: Not Installed
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.6.2
mysql-python: Not Installed
pycparser: 2.14
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: 0.26.4
Python: 2.7.5 (default, Apr 2 2020, 13:16:51)
python-gnupg: Not Installed
PyYAML: 3.11
PyZMQ: 15.3.0
smmap: Not Installed
timelib: Not Installed
Tornado: 4.5.3
ZMQ: 4.1.4

System Versions:
dist: centos 7.8.2003 Core
locale: UTF-8
machine: x86_64
release: 3.10.0-1127.18.2.el7.x86_64
system: Linux
version: CentOS Linux 7.8.2003 Core

[pdmlink@saltmaster workers]$

Please help me resolve it as I need to roll this deployment to production ASAP.
Thanks,
Sriram

sriramperumalla · 2020-08-20T14:04:53Z

I take my words back. dict object attribute not found error is due malformed pillar data .sls file.

vikrant-agarwal · 2020-12-17T10:34:06Z

I also get error . salt-master version :- salt-master 2016.11.3 (Carbon) and salt-master version :- salt-master 2016.11.3 (Carbon)

Data failed to compile:

Rendering SLS 'base:ldap' failed: Jinja variable 'dict object' has no attribute 'roles'

sagetherage · 2021-05-12T16:33:56Z

I also get error . salt-master version :- salt-master 2016.11.3 (Carbon) and salt-master version :- salt-master 2016.11.3 (Carbon)

Data failed to compile:
Rendering SLS 'base:ldap' failed: Jinja variable 'dict object' has no attribute 'roles'

@vikrant-agarwal Salt v2016.11.3 is no longer supported and breaking changes are likely.

dwoz · 2021-08-16T19:30:20Z

I'm convinced this issue has been fixed by #58369. I am closing the issue for now, if anyone is able to re-produce this in a version >3002 please comment and we'll re-open the issue.

jfindlay added Bug broken, incorrect, or confusing behavior severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around Core relates to code central or existential to Salt P3 Priority 3 Pillar labels Nov 19, 2015

jfindlay added this to the Approved milestone Nov 19, 2015

jfindlay added P1 Priority 1 and removed P3 Priority 3 labels Dec 4, 2015

This was referenced Jun 21, 2016

Wrong line number for UndefinedError exceptions pallets/jinja#276

Closed

Pillar unavailable in orchestrate runner #34169

Closed

jettero mentioned this issue Nov 20, 2016

please tell me where is the “error: 'dict' object has no …” #37795

Merged

smarsching mentioned this issue Mar 10, 2017

Fix race condition in Salt loader. #39948

Closed

smarsching mentioned this issue Jan 30, 2018

Fix race condition in Salt loader. #45782

Closed

dwoz mentioned this issue Sep 4, 2020

[BUG] Thread safety of loader #58369

Closed

sagetherage added severity-high 2nd top severity, seen by most users, causes major problems and removed severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around labels Sep 10, 2020

sagetherage assigned Ch3LL Sep 10, 2020

sagetherage unassigned Ch3LL Sep 29, 2020

sagetherage added Aluminium Release Post Mg and Pre Si and removed Magnesium Mg release after Na prior to Al labels Sep 29, 2020

sagetherage modified the milestones: Magnesium, Aluminium Sep 29, 2020

sagetherage assigned twangboy Jan 4, 2021

sagetherage added phase-plan labels Jan 4, 2021

sagetherage added Silicon v3004.0 Release code name and removed Aluminium Release Post Mg and Pre Si labels Mar 24, 2021

sagetherage modified the milestones: Aluminium, Silicon Mar 24, 2021

sagetherage removed status-in-prog labels Mar 24, 2021

sagetherage assigned dwoz and unassigned twangboy May 12, 2021

sagetherage modified the milestones: Silicon, Approved Aug 12, 2021

dwoz closed this as completed Aug 16, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

state.sls fails to render state with pillar data: Jinja variable 'dict object' has no attribute #29028

state.sls fails to render state with pillar data: Jinja variable 'dict object' has no attribute #29028

kevins9 commented Nov 19, 2015

kevins9 commented Nov 19, 2015

jfindlay commented Nov 19, 2015

kevins9 commented Nov 19, 2015

jfindlay commented Nov 19, 2015

joberget commented Nov 26, 2015

jfindlay commented Dec 1, 2015

dennsi commented Dec 4, 2015

thegrmpf commented Dec 4, 2015

kucerarichard commented Dec 15, 2015

kevins9 commented Dec 16, 2015

rbjorklin commented Jun 20, 2016 •

edited

Loading

rbjorklin commented Jun 20, 2016 •

edited

Loading

rbjorklin commented Jun 21, 2016 •

edited

Loading

rbjorklin commented Jul 13, 2016 •

edited

Loading

hgfischer commented Jul 10, 2017

IliyanIliev1 commented Aug 23, 2018

rbjorklin commented Aug 23, 2018

sriramperumalla commented Aug 19, 2020 •

edited

Loading

sriramperumalla commented Aug 20, 2020

vikrant-agarwal commented Dec 17, 2020

sagetherage commented May 12, 2021

Data failed to compile:

dwoz commented Aug 16, 2021

state.sls fails to render state with pillar data: Jinja variable 'dict object' has no attribute #29028

state.sls fails to render state with pillar data: Jinja variable 'dict object' has no attribute #29028

Comments

kevins9 commented Nov 19, 2015

Version info - master and minion

Pillar top.sls

Pillar bugdemo.sls

minion /etc/salt/grains

Master /srv/salt/dev/bugdemo.sls

Evidence

kevins9 commented Nov 19, 2015

bugdemo.sls

Works correctly on the good minion

Works incorrectly on the bad minion

jfindlay commented Nov 19, 2015

kevins9 commented Nov 19, 2015

jfindlay commented Nov 19, 2015

joberget commented Nov 26, 2015

jfindlay commented Dec 1, 2015

dennsi commented Dec 4, 2015

thegrmpf commented Dec 4, 2015

kucerarichard commented Dec 15, 2015

kevins9 commented Dec 16, 2015

rbjorklin commented Jun 20, 2016 • edited Loading

rbjorklin commented Jun 20, 2016 • edited Loading

rbjorklin commented Jun 21, 2016 • edited Loading

rbjorklin commented Jul 13, 2016 • edited Loading

hgfischer commented Jul 10, 2017

IliyanIliev1 commented Aug 23, 2018

Hello All, I have the same error , and no idea WHY -----------------------------------------------error--------------------------------------------------------------------------------- ill.sofia.elex.be: Data failed to compile:

rbjorklin commented Aug 23, 2018

sriramperumalla commented Aug 19, 2020 • edited Loading

sriramperumalla commented Aug 20, 2020

vikrant-agarwal commented Dec 17, 2020

Data failed to compile:

sagetherage commented May 12, 2021

Data failed to compile:

dwoz commented Aug 16, 2021

rbjorklin commented Jun 20, 2016 •

edited

Loading

rbjorklin commented Jun 20, 2016 •

edited

Loading

rbjorklin commented Jun 21, 2016 •

edited

Loading

rbjorklin commented Jul 13, 2016 •

edited

Loading

Hello All,
I have the same error , and no idea WHY
-----------------------------------------------error---------------------------------------------------------------------------------
ill.sofia.elex.be:
Data failed to compile:

sriramperumalla commented Aug 19, 2020 •

edited

Loading