Open doubletwist13 opened 6 years ago
This seems to be a pillars issue, and not a formula issue, so I'm not sure if the formula (this or any other) is the correct place to add this logic you're mentioning.
Personally, I use pillarstack to manage these cases, where you can set a hierarchy of pillar files which will be read by some nodes and not others. It allows to merge values, ovewrite them, conditionally add parameters to some hosts, etc. It's quite powerful and I think it can allow you to do what you're mentioning (If I'm undertanding your use case correctly?)
Yes, I think that probably will do what I need. Thanks!
The concept is simple but it's difficult for me to put into words so hopefully this all makes sense.
I have some server types that needs some extra packages that I don't want installed elsewhere but that don't necessarily need a whole role/formula defined for them. Everyone I talk to suggests that putting too much logic in a single init.sls pillar is not best practice, and that makes sense to me. It seems the best way to do this is leave the logic in top.sls like this:
/srv/pillar/top.sls
/srv/pillar/packages/init.sls
/srv/pillar/packages/srvtype.sls
With this setup the 'srvtype*' minions only see 'otherpackage' as wanted as it overrides the packages in init.sls instead of merging.
I know it's possible to set salt master to always merge lists but I don't think that's the best way to go.
It would be fantastic if the formula could merge them, either by logic in the formula I guess, or by setting up the formula to get pillar data as a dictionary instead of lists? I know vaguely what is needed but don't have the chops to actually do it myself.