What's the recommended way for accessing variables from another pillar in a next pillar? E.g. pillar top loads a.sls, then b.sls, how can b refer to a var foo defined by a? I've seen import_yaml mentioned as a workaround, which would be sufficient in my case

<msmith> that's the entire key to dynamic content. in short, make the minion do more of the work and it'll take load off your master. some (many?) people say they don't see a problem and thus no need to change. that's great. but for those with problems it's essential, so we decided to use best practices right from the start

$previous_client had a >24,000 line yaml structure in pillar with lots of configuration data for all systems in the network (including some passwords), and wrote an extremely piss poor custom module -> node_cfg.get(var, hostname, default_value, allow_default_lookup) <- to parse the data structure.

oh, even better... when I verified "cross node lookup" was completely unused, I also noticed that the assumption was made that the module used .get(var, default). I made that true, removed any instance of node_cfg.get(var, grains['id']), fixed other issues in the module, and broke it apart so every host was in it's own dc-based subdir with each node in it's own file, and delivering only

The whole thing was shot down because, "what we have is really good, but it just needs to be broken apart into dc-based files." No amount of explaining how pillar works and the extra load being put on the masters was sufficient. After that person finally left, I was able to force the changes and we saw over a 50% drop in execution time and 80% drop in cpu load.

JPT: Debating how best to phrase it then, since I have some wrappers around salt for my frontend team to be able to deploy applications. Originally I was thinking of just allowing them to push a pkg version in via my util and then on the salt side do "state.apply state.here pillar={"applcation_name":"version"}" with the state reading that in for the version parameter of the pkg.installed state

MTecknology: In some cases yes, planning on doing a switch case in my util based on flaggs to either call a state with an explicit version via pkg.installed and the version param or to call a pkg.latest state

I remember frequently replying "unsubscribe" to an IT newsletter at my college. I knew it did nothing, but I was making a point that the crap they're sending out isn't worth reading. One time someone accidentally replied to me with the message, "He's still trying to unsubscribe. I don't know what to do."

If you create a state to change system.network and an interface...and then remove that state later one - will those changes enforced by the state persist over reboots (aside from other manual typists doing things)?