I think salt is neato, but I also find it very frustrating to use! (Possibly through no fault of salt itself - I feel like I must be missing something.)
I am generally able to SSH into a box and get things configured the way I need. However, I have huge amounts of trouble translating that into salt scripts.
Consider logrotate. Here is the only documentation I can find on the topic [1]. From this, I have no idea what to put in init.sls to make sure a given log file is being rotated correctly. It seems this would work on the cmdline, but not necessarily in a salt script.
And that's just for logrotate! My uswgi + nginx configuration - translating that into salt - I don't know where to begin.
How do I make sure things get installed in a certain order? (Answer seems to be having 10 directives, for 10 packages, each depending on another, to enforce order.)
Is there anything that more closely mirrors what I actually do when configuring the box? SSH in, set certain values, etc? I guess I could write a shell script (or use fabric) but then I seem to have lost the point of configuration management.
> Consider logrotate. Here is the only documentation I can find on the topic [1].
Using Salt's logrotate module might be more than you need. You can always just have salt manage a file in /etc/logrotate.d/ and keep it up to date, which would be a lot easier.
The salt module is meant for more complex, fine-grained tuning of logrotate files, but I'm not really sure why I would use it.
> My uswgi + nginx configuration - translating that into salt - I don't know where to begin.
The approach that I use: check your entire nginx configuration into git (e.g. your whole /etc/nginx directory) and then you can configure salt to check it out and keep it updated.
Also, if you're custom-compiling nginx into /opt/local/nginx or something, you can actually have salt recursively copy the entire directory to your slaves.
Hey memset - these sound like pretty straightforward questions (with straightforward answers). Perhaps asking on the mailing list, or hop onto the #salt channel on freenode IRC?
As one of the people on that list who may well respond there, I'll reply here as well so its on the record.
You will be very well off if you read and 'digest' the Salt docs on States first, before moving on to modules, pillars, grains, custom returners, etc.
What you probably need to do with logrotate is take the configuration that you normaly setup on your servers, then add it to your salt system. So top.sls calls 'logrotate' running the 'logrotate/init.sls' and that has a definition that says "I want logrotate installed, I want it running as a service, and by the way take the file 'logrotate/config.conf' and shove it in /etc/logrotate.d/ as <correct filename>, p.s. If i change that file, restart logrotate"
With States & the requisite declarations to enable salt to know what order things need to be in, you shouldnt have much trouble adding a simple service like logrotate along with a specific config file to use for that service.
I am generally able to SSH into a box and get things configured the way I need. However, I have huge amounts of trouble translating that into salt scripts.
Consider logrotate. Here is the only documentation I can find on the topic [1]. From this, I have no idea what to put in init.sls to make sure a given log file is being rotated correctly. It seems this would work on the cmdline, but not necessarily in a salt script.
And that's just for logrotate! My uswgi + nginx configuration - translating that into salt - I don't know where to begin.
How do I make sure things get installed in a certain order? (Answer seems to be having 10 directives, for 10 packages, each depending on another, to enforce order.)
Is there anything that more closely mirrors what I actually do when configuring the box? SSH in, set certain values, etc? I guess I could write a shell script (or use fabric) but then I seem to have lost the point of configuration management.
[1] http://docs.saltstack.com/ref/modules/all/salt.modules.logro...