Relative includes are not working when being called with state.sls <directory>/<slsfile>

[jnieuwen]

Description of Issue

When calling a state with for example salt mx3 state.sls mailserver/postfix relative includes are not working. When called as salt mx3 state.sls mailserver.postfix they do work.

Setup

mailserver/postfix.sls:

include:
  - .vmail_users


# Make sure the postfix and mail-utils package are installed.
postfix_package:
  pkg.installed:
    - names:
      - postfix
      - mailutils

mailserver/vmail_users.sls:

vmail_group:
  group.present:
    - name: vmail
    - gid: 404

Steps to Reproduce Issue

salt mx3 state.sls mailserver/postfix results in:

# salt mx3 state.sls mailserver/postfix
mx3:
    Data failed to compile:
----------
    Specified SLS vmail_users in saltenv base is not available on the salt master or through a configured fileserver

salt mx3 state.sls mailserver.postfix works as expected

Versions Report

Salt Version:
Salt: 2019.2.2

Dependency Versions:
cffi: 1.11.5
cherrypy: Not Installed
dateutil: 2.4.2
docker-py: Not Installed
gitdb: 0.6.4
gitpython: 1.0.1
ioflo: Not Installed
Jinja2: 2.8
libgit2: Not Installed
libnacl: Not Installed
M2Crypto: Not Installed
Mako: 1.0.3
msgpack-pure: Not Installed
msgpack-python: 0.4.6
mysql-python: Not Installed
pycparser: 2.18
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: Not Installed
Python: 2.7.12 (default, Oct 8 2019, 14:14:10)
python-gnupg: 0.3.8
PyYAML: 3.11
PyZMQ: 15.2.0
RAET: Not Installed
smmap: 0.9.0
timelib: Not Installed
Tornado: 4.2.1
ZMQ: 4.1.4

System Versions:
dist: Ubuntu 16.04 xenial
locale: UTF-8
machine: x86_64
release: 4.4.110-mainline-rev1
system: Linux
version: Ubuntu 16.04 xenial

[xeacott]

This is documented somewhere, I believe I've seen it before but if the state file is not in /srv/salt/ then salt has to know where to look for your state files which is specified by <file_roots>. Basically our <file_roots> translates to salt://, and we use defaults by, well, default. So if you want to define your own, Salt needs to know about them. Here is an example of what I mean...

# In the master config file (/etc/salt/master)
file_roots:
  base:
    - /srv/salt
    - /mnt/salt-nfs/base

From the 'Steps to reproduce above...'

    Specified SLS vmail_users in saltenv base is not available on the salt master or through a configured fileserver

which is why I believe Salt doesn't know about other possible file_roots 😄 I hope that helps!
BTW here is a good read, too.

[jnieuwen]

Hi Joe,

file_roots is not the issue I think:

# salt mx3 cp.list_states | grep mailserver
    - mailserver
    - mailserver.dovecot
    - mailserver.postfix
    - mailserver.vmail_users

To make the issue hopefully more clear:
does work: salt mx3 state.sls mailserver.postfix
does not work: salt mx3 state.sls mailserver/postfix

Note that the only difference is the forward slash vs. the dot between mailserver and postfix

Debug output of the salt-minion when running salt mx3 state.sls mailserver/postfix:

[DEBUG   ] Rendered data from file: /var/cache/salt/minion/files/base/mailserver/postfix.sls:
# Include statements
#   - Make sure we have vmail user.
include:
  - .vmail_users

# Make sure the postfix and mail-utils package are installed.
postfix_package:
  pkg.installed:
    - names:
      - postfix
      - mailutils

[..]

[DEBUG   ] Results of YAML rendering:
OrderedDict([('include', ['.vmail_users']), ('postfix_package', OrderedDict([('pkg.installed', [OrderedDict([('names', ['postfix', 'mailutils'])])]) [..])
[PROFILE ] Time (in seconds) to render '/var/cache/salt/minion/files/base/mailserver/postfix.sls' using 'yaml' renderer: 0.004013776779174805
[DEBUG   ] Could not find file 'salt://vmail_users.sls' in saltenv 'base'
[DEBUG   ] Could not find file 'salt://vmail_users/init.sls' in saltenv 'base'

So it does not even try to search for the correct salt://mailserver/vmail_users.sls file.

[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.

[sagetherage]

@xeacott are you able to take a look at this in the near future?

[stale]

Thank you for updating this issue. It is no longer marked as stale.