salt: Release notes for v3000 do not mention changes to `slspath` variable

For tpldir not being documented: #50925

@dhs-rec And some people are expecting slspath to work as documented. Before, tpldir and slspath did the same thing, and that’s clearly not the intent. In addition, it deprives people of a means to get the path of the SLS file.

Since this has gone completely undocumented AND is a backwards incompatible change, I’d vote for reverting it to the previous behaviour and only then announce it as being deprecated and change it in the second next release. Nothing else does make any sense.

A quick patch:

patches/slspath.sls:

{% if grains.saltversion == "3000" %}
patch:
  pkg.installed

slspath_patch:
  file.patch:
    - name: '{{ grains.saltpath }}'
    - source: salt://patches/files/3000-slspath.diff
    - strip: 2
    - require:
        - pkg: patch

restart_salt_minion:
  cmd.run:
    - name: 'salt-call service.restart salt-minion'
    - bg: true
    - onchanges:
      - file: slspath_patch
{%- endif %}

patches/files/3000-slspath.diff:

diff --git a/salt/utils/templates.py b/salt/utils/templates.py
index d026118269..98092a9d79 100644
--- a/salt/utils/templates.py
+++ b/salt/utils/templates.py
@@ -122,6 +122,8 @@ def wrap_tmpl_func(render_str):
             slspath = context['sls'].replace('.', '/')
             if tmplpath is not None:
                 context['tplpath'] = tmplpath
+                if not tmplpath.lower().replace('\\', '/').endswith('/init.sls'):
+                    slspath = os.path.dirname(slspath)
                 template = tmplpath.replace('\\', '/')
                 i = template.rfind(slspath.replace('.', '/'))
                 if i != -1:

Run sudo salt MINION state.apply patches.slspath to apply the fix.

Another thing I noticed about this change is it made things in-consistent. With the change, running state with the foo/init.sls would return still return the directory where the init.sls is located foo. Running a state within a directory foo/bat.sls wougld return foo/bat.

When the change is reverted both of the above scenarios return foo. Overall, I think the name slspath is very misleading and should be addressed. Perhaps by deprecating it all together and making slsdir instead. I could also see a case for adding slsdir and changing slspath to reflect the actual path (including the file extension).

In any case, for the 3000.1 release, I have reverted the change and updated the documentation for slspath to more accurately reflect the behavior.

Yeah, I agree. The correct move here is to build out the documentation, not to break slspath again.

EDIT: I’ve changed my mind, see below.

I don’t understand how is this going to be resolved. Is the change to slspath value going to become permanent (in which case I need to replace slspath variable with tpldir everywhere) or it’s going to be reverted to the previous value (in which case I just need to wait for the next salt release)?

The commit: https://github.com/saltstack/salt/commit/5a17dd6390aa8ef9a7f6899e6d9ce8be2b6750f3#diff-96d7010eb773dc57ad2c8eb89cd12807

As all (relevant) unittests reported success, it may be a good idea to harden the variables with unittests.

+1. Sure do love these breaking changes.

Add me a +1. This breaks previously working SLS files and it is frustrating to have this happen with ZERO indication.