Feedback, from a newbie ...

[Mike]

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.

[Thomas S Hatch]

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 <geek...@mgmiller.net> wrote:

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."

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
difficult.

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:

/var/www/index_html:
__file:
____- 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:

/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.

 

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

[Mike]

Thanks for the reply.

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

If they are data, why not just call them data? I realize it's kind of
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, a
> string is read as the function to call and the dicts are all arguments

Hmm, I guess my comment doesn't have much to do with yaml but about
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.

[Thomas S Hatch]

On Tue, Apr 3, 2012 at 4:00 PM, Mike <geek...@mgmiller.net> wrote:

Thanks for the reply.

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

If they are data, why not just call them data?  I realize it's kind of
boring but learning a new vocabulary for every tool I use gets boring
too.  Guess I'm getting old.

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.

 

> 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.

Jinja is the default, and few users deviate from it, so it is a dep on the package. Technically it could be considered an optional dep since salt will run without it, btu the sls files will fail to render without it, since it assumes that jinja is there 

> 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

Hmm, I guess my comment doesn't have much to do with yaml but about
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.

This is a good argument, and the more I think about it, the more I think it would be a good idea, I will consider making it an optional way to express the module function

[Mike]

On Tuesday, April 3, 2012 3:12:48 PM UTC-7, Thomas Hatch wrote:

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.

Ok, as a newbie I may laugh at the question in a few months.

 
> This is a good argument, and the more I think about it, the more I think it would be a good idea, I will consider
> making it an optional way to express the module function

Thanks for listening.  If it matters any, seems better for it to be changed or not... two ways of writing them goes against the "There should be one-- and preferably only one --obvious way to do it." zen I subscribe to.

[Thomas S Hatch]

Yes, but making a hard change breaks backwards compatibility, I do not want to mandate that everyone's sls files be modified. I am looking into making this addition right now, I am wondering why I did not think of it originally to be honest

[Christopher Smith]

On Apr 3, 2012, at 3:00 PM, Mike <geek...@mgmiller.net> wrote:,

> If they are data, why not just call them data? I realize it's kind of
> boring but learning a new vocabulary for every tool I use gets boring
> too. Guess I'm getting old.

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...".

[Mike]

That's the beauty of being on version 0.9x ;)  Could we write a 2to3 script like python?

The story about how DOS/Windows came to use the backslash as the path separator comes to mind.  They didn't want to break compatibilty with the programs already written to use the front slash from the previous year or so.  Was the right call at the time.  30 years later we are still suffering for it ... double-backslashing every hard to type path.

If there ever was a time to break compatibility, it is now before 1.0.

[Mike]

Thanks for the commentary, as I learned a few new things.  I'm not sure of the correct answer ... perhaps a css pseudo-class that appends "(Realtime client data)" to each mention of the term in the docs?  ;)

[Mike]

Thinking about it, a clean break is a bit harsh, even before 1.x.  A deprecation schedule would be much friendlier.

[Thomas S Hatch]

Yep, that's the plan :)