Salt: requiring sls file containing only includes fail

[kintel]

I have the following file structure:

includetest/init.sls
includetest/subtestfile.sls
includetest/testfile.sls

init.sls:

include:
  - includetest.testfile

/home/deploy/testfile2.txt:
  file.managed:
    - contents: Hello
    - require:
      - sls: includetest.testfile

testfile.sls:

include:
  - .subtestfile

subtestfile.sls:

/home/deploy/subtestfile.txt:
  file.managed:
    - contents: Hello

When running salt-call state.sls includetest, I get:

    State: - file
    Name:      /home/deploy/testfile2.txt
    Function:  managed
        Result:    False
        Comment:   The following requisites were not found:
                   require:
                       sls: includetest.testfile

Playing around a bit, it appears that this is caused by requiring a file containing _only_ includes. A workaround is to modify testfile.sls to do some arbitrary work.

Is this a bug or by design?
My use-case is to have a file including a bunch of states and requiring that file from various places.
(Tested on 0.17.5)

[basepi]

Likely just an edge-case that we're not handling. Thanks for the report, we'll investigate.

[whiteinge]

I'm speculating that this is due to the require system looking for states in the lowstate that have an __sls__ value that matches the include. Since an sls file that only includes won't create any states that have that value it fails.

[whiteinge]

@kintel A quick workaround would be to make a "dummy" state in the sls which requires those includes:

include:
  - .subtestfile

dummy_testfile_include:
  module:
    - wait
    - name: test.ping
    - require:
      - sls: subtestfile

[kintel]

@whiteinge Thanks - I'm using the dummy strategy already. Note that your example only works on the top level due to #10838

[JustinCarmony]

I ran into this bug as well. We have a "common" sls group that includes all the different sections:

include:
  - common.users
  - common.packages
  - common.services
  - common.tools

I've done the work-around that @whiteinge suggested, but it would be nice not having to have a dummy state.

[spareslant]

@whiteinge and @kintel thanks for suggesting an alternative solution. This was much needed.

[eliasp]

Just wasted ~3h on this bug too until I realized what I was dealing with :)
Using now a simple test.configurable_test_state as workaround which could also be replaced with test.nop (available since 2015.5.6) - depending on the used Salt version.

[boltronics]

@eliasp Join the club. :) It's generally not obvious what the problem is when you hit it. This drove me nuts last year until it was burned into my mind to always watch out for this.

I'm very glad to see this bumped up from Low to High severity at least.

[JaseFace]

It appears for understandable reasons there is same behavior when you include an 'empty' file, say for example you include a file wrapped in conditionals that don't trigger. So more appropriately this bug triggers when you simply include an sls without any states.

[DanyC97]

shame this hasn't been fixed even after 3 y (spent ages to find why i got this issue)

[sean-bennett112]

I also recently ran into this, and it took quite awhile to find this issue and the underlying reason it's failing. Has there been any movement on this? Or at the very least, could the documentation be updated to point out that requiring an empty sls, or an sls that only has include statements, currently fails?

[whiteinge]

This isn't currently being worked on. Two ideas that have been floated is to have Salt's YAML parser automatically add a test.nop state to empty files or to figure out a change to Salt's state compiler that can detect this condition another way.

In the meantime, a docs addition is a great idea. This doc is a good first place to add a warning. @sean-bennett112 are you interested in adding that? You can edit that file directly from GitHub's web UI if you'd like.

[sean-bennett112]

@whiteinge sorry for the late reply. I'd be happy to add a warning to the docs. However, is that the best place to add one? I'd think a better location would be here, given that page tends to be the first or second result in Google when I'm trying to debug a requisites issue.

[whiteinge]

@sean-bennett112 good call! A warning in both wouldn't be too much, IMO.

[Reiner030]

Belated happy 3rd birthday to this bug ;) Is there sometimes a fix to be in sight?
Since on other usages this multilevel references are unproblematic (pillar, grains, sls references for includes) it shouldn't be too problematic / difficult to get here also a solution?

The above mentioned workaround could /has to be used then but I was just trying to avoid single state reference and use a whole sls as required_in because saltstack likes to play dice with state ordering already also in the referenced sls

[hgfischer]

Just hit the nail with this bug now. I guess that's the price to pay for trying to write organized formulas. :(

[stale[bot]]

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.

[kiemlicz]

I think it is still an issue

[stale[bot]]

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

[MalloZup]

update on this?

[MalloZup]

it is a stale issue but still an issue, the bot algorithm need improvements there.

[stale[bot]]

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.

[kiemlicz]

I guess not stale

[stale[bot]]

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

[wayne-weibel]

just hit this same bug, again ... not sure what changed. I was not having this error until very recently. States had been working.