Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release notes for v3000 do not mention changes to `slspath` variable #56119

Open
finalduty opened this issue Feb 10, 2020 · 11 comments
Open

Release notes for v3000 do not mention changes to `slspath` variable #56119

finalduty opened this issue Feb 10, 2020 · 11 comments

Comments

@finalduty
Copy link

@finalduty finalduty commented Feb 10, 2020

Description of Issue

Release notes for v3000 do not mention changes to slspath variable by #55434 / #55433 , which previously returned the parent directory instead of the path to the state file itself.

This functionality appears to be covered by the tpldir variable, but this is not documented on https://docs.saltstack.com/en/latest/ref/states/vars.html.

Can both the v3000 release notes and the SLS Template Variable Reference be updated to make this more visible to others?

Setup

Tree:

/srv/salt/users/
|-- files
|   |-- bash_profile
|   |-- bashrc
|   |-- login.defs
|   |-- root_profile
|   `-- vimrc
|-- init.sls
|-- root.sls
`-- staff.sls

root.sls

/root/.bashrc:
  file.managed:
    - source: salt://{{ slspath }}/files/bashrc
    - template: jinja
    - defaults:
        sls: {{ sls }}

Steps to Reproduce Issue

  1. Apply users.root state

Output:

----------
          ID: /root/.bashrc
    Function: file.managed
      Result: False
     Comment: Source file salt://users/root/files/bashrc not found in saltenv 'base'
     Started: 20:46:08.752499
    Duration: 2.315 ms
     Changes:   
----------

Replacing slspath with tpldir resolves the issue, but this is not an obvious fix.

Versions Report

Salt Version:
           Salt: 3000
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
         Jinja2: 2.8.1
        libgit2: Not Installed
       M2Crypto: 0.33.0
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.6.2
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: 3.7.3
         pygit2: Not Installed
         Python: 3.6.8 (default, Aug  7 2019, 17:28:10)
   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.7.1908 Core
         locale: ANSI_X3.4-1968
        machine: x86_64
        release: 3.10.0-1062.9.1.el7.x86_64
         system: Linux
        version: CentOS Linux 7.7.1908 Core
@ryanmilne-digicert

This comment has been minimized.

Copy link

@ryanmilne-digicert ryanmilne-digicert commented Feb 10, 2020

+1

I was about to create an issue for the exact same problem. Good find with the tplpath variable.

@tomwalsh

This comment has been minimized.

Copy link
Contributor

@tomwalsh tomwalsh commented Feb 11, 2020

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

@PaulChristophel

This comment has been minimized.

Copy link

@PaulChristophel PaulChristophel commented Feb 11, 2020

+1. Sure do love these breaking changes.

@OrangeDog

This comment has been minimized.

Copy link
Contributor

@OrangeDog OrangeDog commented Feb 11, 2020

For tpldir not being documented: #50925

@max-arnold

This comment has been minimized.

Copy link
Contributor

@max-arnold max-arnold commented Feb 12, 2020

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.

@danlsgiga

This comment has been minimized.

Copy link
Contributor

@danlsgiga danlsgiga commented Feb 12, 2020

Just hit this wall too and changed all my {{ slspath }} code blocks for the undocumented {{ tpldir }} one.

@commonism

This comment has been minimized.

Copy link

@commonism commonism commented Feb 13, 2020

The commit:
5a17dd6#diff-96d7010eb773dc57ad2c8eb89cd12807

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

@brandon-sling

This comment has been minimized.

Copy link

@brandon-sling brandon-sling commented Feb 13, 2020

This is tangential but I was wondering why slspath and tpldir were the same in previous versions. I have almost filed an issue in the past to see if slspath could be updated to do what it does now, and document tpldir

@dkacar-oradian

This comment has been minimized.

Copy link

@dkacar-oradian dkacar-oradian commented Feb 17, 2020

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)?

@dhs-rec

This comment has been minimized.

Copy link
Contributor

@dhs-rec dhs-rec commented Feb 18, 2020

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.

@sagetherage

This comment has been minimized.

Copy link
Contributor

@sagetherage sagetherage commented Feb 18, 2020

Looking into this @dkacar-oradian @dhs-rec we will add this to the this week's Community Open Hour on Thursday at 11 AM Mountain and get more details in this ticket. Apologies! I didn't see this early, Monday was a US holiday and simply catching up, not to defend or give you and excuse, we need to hear from you and deal with this ASAP, simply giving context for the lack of a more prompt response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.