I apologise to anyone seeing this for a second time*
Can anyone suggest some documentation source, or a heavily commented set of files which might help me to understand the concepts and terminology behind and underlying salt.
I’ve tried the salt upstream, and various other sites, but I found myself confused by a lot of the docs and guides, which seem to confound the concepts I am familiar with, like execution, state, action, etc.
Even after several attempts, I do not have an intuition about pillars, grains, salt stacks, and so on. Maybe I am looking for too much meaning in the names, and there are not really clever metaphors in there.
Maybe it’s more obvious if one comes from ansible or something similar, but I don’t… and every time I try to work out what is happening in Salt it makes me feel really stupid!
Who can help me to un-stupid myself?
* this is an edited duplicate of my unthinking hijack attempt here :
There’s a guide on the Forum.
You could also take a look at my notes which include
notes on salt with examples, which take you though from absolute basic
use up to more complex worked examples.
These are from a course I’ve run, but they should give you an idea of how
to get started with salt.
These are just terms that press the salt metaphors a little too hard. In Qubes
pillar - system wide storage of variables and parameters, that can be
used within salt states.
grains - information derived in individual qubes/templates
salt stack - Howling Wolf can tell you more.
You can be productive with salt in Qubes within minutes. (Instead of
installing packages in templates, write states that install the packages
then you have a record of what you have done, and can easily
replicate your system after backing up these states.)
You can leverage the large number of salt modules, but in truth you
can build a system using very few.
If you need specific help, just ask.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Thank you, All, for your replies.
More are welcome. I think I have looked at all the sources above, but never at the same time, and probably none to the depth they deserve.
I am beginning to understand my problem with understanding…
@unman has cleared my doubt about the “salty” metaphors. Maybe the most useful one I imagined is that “grains” are sprinkled around multiple hosts, and the “pillar” is in the master “temple” (?).
Without anyone trying to answer all my questions, I am wondering:
How much, and how, folk use different methods for managing their states and setups. :
Permanently enabled “tops”, and for what purposes? For updating? Others?
A top file is not necessary, I think, but for recording what you have done or for repeating and reimplementing, do you make them anyway? Otherwise it seems like I just need a higher level of my “big list of previous actions”. Or keep a directory per target, to keep a collection of the SLS applied to each target? Or do you rely on the system journal…?
Just one-off applications?
Other tricks for keeping track of what has been done, and where?
Tricks for undoing…
I suppose I am thinking of several distinct uses…
Re-creation of my personal setup, with salt plus backup restores. A full duplicate.
Duplication/provisioning a new machine, with my preferred configuration (or someone else’s).
Playing with e.g. sys-gui/management-vm and similar, with the possibility to scrap a set of badly set-up VMs, and start again.
They retain the known state. When you have something configured through salt you can just highstate to make sure that the salt files override any other (maybe accidental) changes.
When you have everything set up using top files and state it makes it trivial to update your template VMs, which is something I’ve heard people have issues with in qubes when they modify the template manually and lose all those changes when they update.
Salt is VERY good for letting you recreate your system (as others here have noted). As a result I only bother backing up about five different VMs (one of which is a “repository” that I keep copies of salt files on–and I manage two different systems with it); anything else I can recreate if there’s a hard “crash” of my system.
I end up using a combination of salt and bash, because I like to clone a vm, add software, clone that VM and add more software to the second clone. There’s no way I can find to prevent Salt from doing the second clone immediately after the first clone–i.e., before it finishes installing software on the first clone (since the cloning happens on dom0 and the installing happens in the VM).
One other thing to watch out for: If you find this section in the QubesOS documentation: Salt (management software) | Qubes OS it is titled “All Qubes Specific States” which is misleading, it doesn’t list all of them (unless someone has updated it in the last couple of years). Scroll down to the bottom of the page and there is a link labeled “Qubes Specifc Modules” (qubes-mgmt-salt-dom0-qvm/README.rst at master · QubesOS/qubes-mgmt-salt-dom0-qvm · GitHub) which IS complete (and there’s some useful stuff in there).
More gold is here, from @SteveC@PolyT , adding to @solene and @dhimh (not forgetting @unman, of course) - thank you all. I think I needed a wider perspective, and this has helped a lot.
I feel there must be a solution to the problem of how to
It seems to me like that would be quite educational.