Questions & Feedback for SaltStack

salt.md

Questions & Feedback for SaltStack

I've read as much introduction documentation as I can find. Here are some outstanding questions that I'm still seeking answers for. Links or answers in comments are welcome.

Questions

1. Is it possible to define salt configurations for different server roles (e.g. webserver, database, loadbalancer, etc) which could be distributed to an arbitrary number of servers? (e.g. one server that is a {webserver,database,loadbalancer} or three servers where each is one of the kid.) I have a feeling this has something to do with Grains, but not sure how.

   Answered: Use grains or nodegroups.

2. Can a directory be referenced from salt://foo/bar if foo/ does not have an init.sls? Are there downsides from keeping sls configuration separate from statis assets that get deployed?

   Answered: Yes. No downsides, just organization.

3. Is there any guarantee on the order that sls definitions get executed? Or is there a way to specify dependencies? (For example, I need to make sure that libjpeg-related libs are symlinked to unusual places on Ubuntu before I can install the Python Imaging Library.)

   • I feel like this could be done by specifying a target which is the expected symlink target (although there's like 4 of them), but that's a long messy string (example: sym.sls) — Is there another way?

4. I keep seeing absent.sls in various directories, what does that do? (Can't find a mention in the docs.)

5. Pillars: Is there a way to specify default pillar valus, and then be able to "pass in" overrides?

Feedback

1. It took me a while to figure out that foo.sls and foo/init.sls is equivalent. It would be better if the documentation started by explaining design paradigms like this. (Coming from Python, it would have been more obvious if it was foo/__init__.sls and much easier to spot in a directory full of *.sls and other files.)
2. The terminology is not obvious. What's a State? What's a Pillar? Is there such a thing as a Stack? Are there other kinds of states other than a "high state"? (The minion/master stuff is pretty well-defined, though. And I kind-of have a grasp of Grains)
3. top.sls is a strange choice of magic word. I would have expected root.sls or maybe just a root-level init.sls.

1. yes, use grains or nodegroups: https://salt.readthedocs.org/en/latest/ref/states/all/salt.states.grains.html?highlight=grains https://salt.readthedocs.org/en/latest/topics/targeting/nodegroups.html?highlight=nodegroup

2. I doubt salt will care where the file is in the file structure, as long as it's accessible to salt and in the states folder. The downside being organization, I generally try to keep relevant files with their states.

3. This would involve overstate. The concept of the Over State is managed on the master, a series of state executions is controlled from the master and executed in order. If an execution requires that another execution first run without problems then the state executions will stop.

https://salt.readthedocs.org/en/latest/ref/states/overstate.html?highlight=execution%20order

You can always use the -unless or -onlyif statement in your SLS to make sure a file/directory/thing exists before executing a command as well, but depending on the order it's executed (in a normal highstate) you may have to run highstate twice.

4. Not sure honestly.

Feedback:

1. N/A

2. Stuff is mostly in the docs, takes some getting used to https://salt.readthedocs.org/en/latest/ is the best resource

3. You can set this to something else in the master config:

#####      State System settings     #####
##########################################
# The state system uses a "top" file to tell the minions what environment to
# use and what modules to use. The state_top file is defined relative to the
# root of the base environment as defined in "File Server settings" below.
#state_top: top.sls