Before I was using salt, I was using scripts to set up virtual machines; one for each.
I’m still using scripts, only now they invoke salt. Salt normally operates through “tls” (top level something-or-other) files. One of the things you’ll end up learning is that every invocation has a “target” and it may not be intuitive. To create a VM the target is dom0 (since it actually performs the task); but when you want to install software, muck about with configuration or “dot” files, etc. your target will be the VM itself. Salt will start that VM and execute commands on it. (My scripts could do something similar, but it took some hoop-jumping…I had to run a script on dom0 that copied my other script onto the VM, then dom0 had to do a qvm-run on the machine to tell it to execute the install script.)
So now as I set up minimal templates, it goes something like this: Create Template A (target dom0). Configure Template A (target: template A). Then clone Template B from template A (target dom0), because B is A plus a couple of apps. Configure Template B (target Template B).
The problem is I couldn’t for the life of me get Salt not to immediately clone B from A after creating A (but before A was configured). There was no way to tell dom0 to kindly wait for Template A to finish doing its thing before moving on, not within one tls or sls file anway. It could be done by breaking dom0s task up into multiple sls files, but then…I needed a bash script to manage that.
So I generally run salt from a bash script now. Even so it still has its advantages. It’s smart enough not to install things that are already installed (my scripts were not), and also smart enough to realize that something that is installed now can be updated. (It also integrates well with the Qubes updating scheme; I can get the updater to run my salt states.) So to update a template I re-run the configuration salt formula (I sometimes also run the create one, but since the VM already exists it just resets prefs and features if they have been changed, or changes them if you changed your salt file). Since I was able (with a bit of convoluted variable setting) to get Template B’s configure file to include Template A’s configure file, it will update everything, including the stuff cloned over from A. In fact, I can do this even if A has been deleted.
I was able to copy all of the salt stuff (and configuration stuff that salt installs) to my laptop, and run it there (and fix incompatibilities as they arose). But you could do all that with scripts.
One thing that just flatly doesn’t work with salt is updating the menus. The gui way to do this is to go to the applications tab in the settings window and refresh. (But note that if you do this in a named disposable it will not reasses what’s in the templateVM, only what’s in the disposabel template.) On the command line, qvm-sync-appmenus is the command that should “fix” menus and it works…from the command line. It must be run in dom0. You have to start the VM, then run qvm-sync-appmenus, then shutdown the VM. Setting up a dom0-target salt file to do these three steps simply doesn’t work. The states execute but there’s no effect; the things qvm-sync-appmenus are supposed to affect are not affected. This is another reason I’m still using bash scripts; once I have created and configured my VM, i start the VM, run qvm-syn-appmenus, then shut it down again in the script.
