Unable to access salt dunders from global scope within py pillar templates.

[dlanderson]

Unable to access salt dunders from global scope within py pillar templates.

(salt-dev)root@salt:/srv/pillar/base# cat top.sls 
base:
  '*':
    - pytest


(salt-dev)root@salt:/srv/pillar/base# cat pytest.sls
#!py

file_roots = __opts__['file_roots']

def run():
    return {__name__: file_roots}


(salt-dev)root@web1:~# salt-call pillar.data
local:
    ----------
    _errors:
        - Rendering SLS 'pytest' failed, render error:
        - name '__opts__' is not defined

Changing the pytest.sls file so that it runs just once without render errors:

(salt-dev)root@salt:/srv/pillar/base# cat pytest.sls
#!py

file_roots = "blah"

def run():
    return {__name__: file_roots}


(salt-dev)root@web1:~# salt-call pillar.data
local:
    ----------
    pytest:
        blah

Now change pytest.sls back to using opts dunder:

(salt-dev)root@salt:/srv/pillar/base# cat pytest.sls
#!py

file_roots = __opts__['file_roots']

def run():
    return {__name__: file_roots}


(salt-dev)root@web1:~# salt-call pillar.data
local:
    ----------
    pytest:
        ----------
        base:
            - /srv/pillar/base

It will stop working again when the master is restarted. Also, if you get it to render once without errors it will only work with that one master thread:

(salt-dev)root@web1:~# for i in `seq 1 10`; do salt-call pillar.data; done
local:
    ----------
    _errors:
        - Rendering SLS 'pytest' failed, render error:
        - name '__opts__' is not defined
local:
    ----------
    pytest:
        ----------
        base:
            - /srv/pillar/base
local:
    ----------
    _errors:
        - Rendering SLS 'pytest' failed, render error:
        - name '__opts__' is not defined
local:
    ----------
    _errors:
        - Rendering SLS 'pytest' failed, render error:
        - name '__opts__' is not defined
local:
    ----------
    pytest:
        ----------
        base:
            - /srv/pillar/base
local:
    ----------
    _errors:
        - Rendering SLS 'pytest' failed, render error:
        - name '__opts__' is not defined
local:
    ----------
    pytest:
        ----------
        base:
            - /srv/pillar/base
local:
    ----------
    _errors:
        - Rendering SLS 'pytest' failed, render error:
        - name '__opts__' is not defined
local:
    ----------
    _errors:
        - Rendering SLS 'pytest' failed, render error:
        - name '__opts__' is not defined
local:
    ----------
    pytest:
        ----------
        base:
            - /srv/pillar/base

The dunders work as expected if accessed within the run() function:

(salt-dev)root@salt:/srv/pillar/base# cat pytest.sls
#!py

def run():
    file_roots = __opts__['file_roots']
    return {__name__: file_roots}

[scoates]

FWIW, I dug into this pretty seriously, earlier this week.
The problem here is that the module code is parsed by imp before the dunders have been added, so if it can't compile, it bails.

The order of operations is roughly:

1. import the code in your "module" (python parses the module at this time, and fails because there are referenced-yet-undefined variables) https://github.com/saltstack/salt/blob/develop/salt/utils/templates.py#L343
2. add the dunders https://github.com/saltstack/salt/blob/develop/salt/utils/templates.py#L348
3. call run https://github.com/saltstack/salt/blob/develop/salt/utils/templates.py#L351

You're right that the workaround is to guard them within a function.
Perhaps the whole thing could be guarded within an outer function, by Salt (or the py renderer) itself?

At the very least, the exception raised by load_source should probably be caught, and a better error message should be passed on to the user.

[basepi]

Thanks for your detective work, @scoates! We definitely should at least improve the error message here, pending a better solution.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.