Allow / in pillar includes

[waynew]

What does this PR do?

Re-allows / in pillar includes

What issues does this PR fix or reference?

#51832

Previous Behavior

Using fnmatch stopped us from allowing / in our pillar includes.

New Behavior

re-allow /

Tests written?

No(t yet)

Commits signed with GPG?

Yes

---

This works but I'm not certain if this works too broadly. For instance, if you wrote:

  include: foo/bar.bang/thing

It would look for foo.bar.bang.thing. Is that reasonable, or should I throw in a check to make sure that there is no . in the sub_sls before I do the replacement?

[dwoz]

@waynew does this have a test that verifies the behavior?

[waynew]

@dwoz not yet - I wanted to make sure that this behavior makes sense before I went and wrote the test for it.

i.e. should all of these be the same as include: foo.bar.bang.quux?

• include: foo/bar/bang/quux
• include: foo.bar/bang.quux
• include: foo/bar.bang/quux

If the answer is yes, I'll get that test knocked out... otherwise... should I just make it so

• include: foo/bar/bang/quux is equivalent, while include: foo.bar/bang.quux is something different?

[dmurphy18]

@waynew also capturing it here, needs to support leading dot as in :

• include: .foo.bar.bang.quux

[waynew]

@dmurphy18 So... I have some mixed feelings about my current PR.

On the one hand, yes, it does work for allowing / and a leading .

The part I'm questioning is that technically this introduces a new feature, i.e. relative pillar includes. Before, a leading . worked, it was just a nop. Now the include will be relative to the path of the pillar file doing the include.

Should I break this up into multiple PRs, one restoring the behavior, and one with the improvement?

[dmurphy18]

@waynew I would be in favor of splitting, an issue per fix is my motto.