Google Groups

Re: Feedback, from a newbie ...

Thomas Hatch Apr 3, 2012 1:11 PM
Posted in group: Salt-users
Thanks for the input, I imagine that a number of things sound odd when coming from other somewhat similar systems. let me answer some questions

On Tue, Apr 3, 2012 at 1:29 PM, Mike <> wrote:

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:

____- managed
____- source: salt://webserver/index_html
____- require:
______- pkg: apache

The syntax has been laid out to be as simple and readable as possible, a string is read as the function to call and the dicts are all arguments

Why is the string "managed" the first item in the list?  Followed by a
list of dictionaries for the attributes? I guess I'd expect something
closer to a dict of dicts to model attributes:

________source: salt://webserver/index_html
____________pkg: apache

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.

- Thomas S Hatch