Hi,
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."
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
difficult.
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.
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 /?
Finally, I'm not very familiar with yaml and found some of the syntax
confusing. (added _ to preserve spacing.) From the docs:
/var/www/index_html:
__file:
____- managed
____- source: salt://webserver/index_html
____- require:
______- pkg: apache
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:
/var/www/index_html:
____file.managed:
________source: salt://webserver/index_html
________require:
____________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.
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.
Thanks for the reply.
If they are data, why not just call them data? I realize it's kind of
On Apr 3, 1:11 pm, Thomas S Hatch <thatc...@gmail.com> wrote:
> Grains are meant to be smaller and static pieces of data, so yes, grains of
> Salt, while pillar is a central source of data
boring but learning a new vocabulary for every tool I use gets boring
too. Guess I'm getting old.
> As for jinja, you can get away with using other templating systems if you
> read sls files in xml, or practically anything if you like.Jinja was installed though whether I wanted it or not. Perhaps
another packaging bug? I am using Django templating elsewhere, but
for now plan to use static files.
> The syntax has been laid out to be as simple and readable as possible, aHmm, I guess my comment doesn't have much to do with yaml but about
> string is read as the function to call and the dicts are all arguments
the data modeling. Wouldn't arguments be better modeled as a
dictionary and not a list of one item dictionaries? See below:
>>> load(doc)
{'/var/www/index.html': {'file': ['managed', {'source': 'salt://
webserver/index.html'}, {'require': [{'pkg': 'apache'}]}]
}}
vs.
>>> load(doc2)
{'/var/www/index.html': {'file.managed': {'source': 'salt://webserver/
index.html', 'require': {'pkg': 'apache'}}
}}
or perhaps:
>>> load(doc3)
{'/var/www/index.html': {'file': {'method': 'managed', 'source':
'salt://webserver/index.html', 'require': {'pkg': 'apache'}}
}}
I suppose if you wanted to accept a number of arguments, some of which
may be duplicates, as in a web posting it would be necessary. But it
seems complicated for this application.
Heh, there are a number of ways to use data in Salt, having the data stores separate makes sense I think. I think that as you become more familiar with the data layouts.
It's a perfectly legit frustration; nobody want to learn a whole new vocabulary for each system they use. But I've come to appreciate the value of this approach.
The shared vocabulary we have is very generic. I can't think of software that doesn't have data, but 99.9% of it isn't used the same way Salt uses it (every app has this property), and wouldn't serve as "grains" or "pillars" without some massaging. Even the destiction between grains and pillars is specific: what constitutes "big" and "small" collections of data is very mucg tied to the application. So having unique name, becomes a good way to allow people who know the tool speak precisely, without being confused by the ambiguities. Your challenges with State highlight the problem with *not* having a distinct vocabulary. I know it is tedious when you start, but assuming the terminology has some internal consistency, it doesn't last long, and quickly you benefit from having a precise short hand.
--Chris
P.S. And here is where I mock myself...
I do get annoyed by "States". They really strike me as more idem potent transition models than states. However, that's a function of my frame of mind being more declarative.
Particularly configuration management seems to have all become about building declarative DSL's, and while Salt has declarative elements, I think an interesting characteristic of Salt is that it's coming at the problem from a more imperative mind set; at its most fundamental level, Salt is a system for *doing things consistently* at scale, whereas most CM tools are more *maintaining consistent state at scale*. Yes they are two sides of the same non-trivial problem, but the different vantage point is part of what keeps me from classifying Salt as "yet another...".