Thanks for starting the project. It comes at a good time as I'm going
to be managing some memory-constrained hosts and would prefer to keep
everything in python.
I started playing with salt this weekend, and while powerful, there
are a few things I've had trouble getting my head around.
One is the terminology used. I realize they are part of a fun salty
theme, and I wouldn't want to squash personality but I have had to
look them up several times each reading thru the docs. For example...
States, to me this one is the most direct terms, but doesn't seem to
fit exactly. I think of this is a property of being, but the project
uses them for "recipe files to acheive a state."
The main goal here is more along the lines of "salt controls everything by managing the flow and state"
Since salt states are the components of a configuration management system and are made to control the atomic state of individual components I called them states.
Minion seems on target, but grains, pillars? These mean nothing to me
and I have to look them up every single time I encounter them.
Eventually they should penetrate my thick skull but until then it's
Grains are meant to be smaller and static pieces of data, so yes, grains of Salt, while pillar is a central source of data
Also, I realize salt is made for managing zillions of hosts, but I'm
just starting. I couldn't find a description in the docs on how to
run a minion without a master and premade config files. I didn't want
jinja but it installed it anyway. I'll grow into those at some point,
but not today so am looking to keep things simple. Also, I configured
it for one worker only and nothing to do but it was still running 4 or
5 processes and healthy amounts of ram.
The master is made to handle a lot of traffic, and separates out functions into many processes, a master with only one worker will have a number of process managing individual components.
As for jinja, you can get away with using other templating systems if you want, the way sls files are read is via the renderer interface, so it you want to write a renderer for some other templating language you can. The same goes with the use of yaml, you could very well write a renderer that read sls files in xml, or practically anything if you like.
Next, the ubuntu ppa created a top level /srv folder on the filesystem
with nothing in it, ... which I thought was a bit rude. There are
files in multiple locations but I'd prefer them to be under /etc and
perhaps /var only. Would it be possible to reduce the number of file
locations and stay off /?
Yes, just configure the file_roots option in the master config to go somewhere else, and the ubuntu package should not make a /srv directory, that is a packager bug
Finally, I'm not very familiar with yaml and found some of the syntax
confusing. (added _ to preserve spacing.) From the docs:
Also as 4 space indents are the PEP 8 standard (which I have my editor
set to), the two space indents make things harder to edit. The
recipes don't seem particulary nested so haven't yet seen an advantage
to the horizontal reduction.
The files are yaml, the recommended yaml spacing is 2 spaces. of course you can use 4 if you like
Hope this doesn't sound like I'm complaining, and a new pair of
eyeballs and these comments are helpful. Please correct me if
anything here is incorrect, and thanks again.
In the end, there are a lot of terms, yes, but there are a lot of pieces. One of the goals of Salt is to make all of the components available, so that you can mold it to your environment.
If you don't like yaml/jinja try using another renderer, thats why we support any kind of renderer.