OK I’m trying to tinker with salt to learn about it.
Basically I’m going from a Sven-like set of scripts to set up a bunch of minimal templates, to doing the same thing in salt.
So the general situation is: Starting with debian-11-minimal, I do a clone to template A. A just has updates run on it; and then I clone it to make B. I add a bunch of “general” things to B (and configure aliases and the like), then from B I clone C1 and C2, and then a “tree” grows from there.
Cloning turns out to be something that can be run in the dom0 environment, and so I can write a bunch of top files, one for each template, and I can even write them so that they happen in the proper order. And it will all happen with a simple qubesctl state.highstate
But by itself it misses the point; I want to do the configuration of, say B, before cloning C1 and C2 from it. And from what I could see a lot of this configuration has to happen in a different environment; for example the configuration of B must happen in the B environment.
So the top file for the B template, b-setup.top looks something like this:
base:
dom0:
- b-clone
b:
- b-configure
And things happen in the proper order when I enable b-setup.top.
OK, so b-clone is an sls file that does the clone, and, because commands like qvm-prefs, qvm-tags and qvm-features are commands run in dom0 that specify their target vm, I can put those in b-clone.sls as well.
b-configure, on the other hand, oftentimes has to append things to files on template B, or copy files to B. All stuff best done ON the B template, and using the B environment will cause it to happen…and it happens after the cloning. (Apparently the things in a top file execute seriatim.)
The trouble begins when I enable a-setup.top and b-setup.top at the same time and then invoke qubesctl --target b state.highstate. That should update B, working on A if necessary.
What happens is a-clone is run, then b-clone. As b-clone is being run, however, a-configure is also being run. I actually wanted b-clone to wait until a-configure was done.
(And then, if there is a C1 and C2 enabled, they too will be cloned, even though I was trying to generate B and no further. But as far as I can tell, neither C2 nor C2 gets configured. The answer to this one, at least, seems easy; just be careful what you enable.)
So, I’ve been totally unable to figure out how to get b-clone to depend on a-configure in such a way that it won’t start until a-configure is done. There doesn’t seem any provision at all for getting top files to depend on each other. Apparently the system is smart enough to recognize the clones depend on each other, but I can’t get them to depend on something not in the dom0 environment.
How do I do this?
Ultimate goal: Ideally I’d like to be able to readily–1) generate all vms in the tree from nothing but a copy of debian-11-minimal. 2) update a particular VM, including updating its entire line of ancestry. 3) cause updates to everything, for instance when debian-11 has an update, applying the update to every VM in the tree without having to regenerate them. (That’s a nice-to-have; certainly I could blow all the VMs away and regenerate them all with one command…overnight.