How to make a salt state on target A require a state on target B?

User Support General
1

I think you missed my point. Updating the menu with qvm-sync-appmenus isn’t merely unwieldy in salt. It does not work at all. The call has no effect whatsoever. So I have to do that part, at the very least, in a script. (And I got really, really tired of having to “manually” fix my menus and desktop shortcuts every time after running salt to regenerate qubes.)

You and I did go through a discussion regarding disposable templates (I don’t recall all of the details) and were able to resolve one case, but the resolution broke other cases. I ended up…again in a script…having to either set the default menu items or menu items in a certain sequence, depending on whether a qube was a template, an (ordinary) appvm, an appvm that was a dvm template, or a named dvm, all after the qube was otherwise set up. If I didn’t handle the cases differently from each other, something would “break” and I’d have desktop shortcuts that didn’t function and/or a dvm template that didn’t show up in the menu properly.

As for the other issues, I know I brought up the issue of a qube being cloned by dom0 before that qube ran the states to configure itself, and that conversation sort of trailed off at that point (after someone told me how to combine states in a TLS file, but his advice was irrelevant to my situation and you and I both recognized that).

So returning to that: is it possible to make a state on target dom0 require a state on target some-template-VM, which means a state in a different sls file in a different “environment”?

If so I could certainly do more things with tls files and fewer things with bash scripts. (As of right now, just running updates is the closest I come to running pure salt; there’s no order dependency there and I use the bash script simply to assemble the rather unwieldy salt command line for me.)

2

This isn’t my experience.
That said, I now set the menus using qvm.features, set menu-items,
default-menu-items
Include this as part of the clone state, and when creating qubes.

Obviously that needs a separate thread. Perhaps this discussion should
be broken out too.

It’s not a different environment - it’s all base, or user, or whatever.

I’m not clear on what you mean by “require” in this context - it’s easy
to make a state depend on the results of a state being run, by using
pillar date, or by testing for the potential outcome. Is that what you
mean?
Again, I think this warrants a separate thread: a concrete example would
be good to work with. (Not necessarily the states - an explanation of
the outcome would do.)

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
1 Like
3

In the case of the menus, it was an existing thread and I tried on a couple of occasions to draw your attention back to it with @unman, with no success. I infer either a) that’s not the way to do it or b) you were having comms difficulties at the time.

I could try digging up the other thread (about sequencing of states) too, but there’s no point if I don’t know how to enable you to read the thing. I don’t know what the email-only experience “looks” like so I can’t figure out how best to bring old issues back to your attention. I’m also not sure if you can go back and read an entire thread with just one “attention flagger” or whether I should requote all of the relevant parts.

Right now I know you’re paying attention to THIS thread but don’t have any notion how to redirect you to other, existing threads where I have brought up these issues already. Meanwhile you want to split these topics…and I don’t know how to do that either without losing you.

1 Like
4
Moderation note

I’ve split of the last few posts starting with …

… into this new thread as requested by @unman. (This will work @SteveC :wink:

1 Like
5

A post was split to a new topic: Salt menu stuff

6

I brought up two complaints here, and the menus are one of the two (and yes I remember you were wondering if I had gotten anywhere with that); the other was sequencing.

Sequencing, explained as succinctly as possible (since @unman asked me to): Create Template A, in the base state (meaning dom0 does the work).

I then want the following to happen: Configure Template A (template A does the work). Then once Template A has all the stuff I want installed on it, I want to clone it to template B (and then install more stuff on template B). Dom0 would do the cloning of course.

My attempts to Salt this have resulted in dom0 creating template A, then immediately cloning it to template B, without waiting for template A to configure itself. When I asked about this before, someone (not unman) jumped in with a solution that made it clear he didn’t understand the issue, and unman correctly pointed out the issue wasn’t addressed by the proposed solution. But unman did not suggest a solution himself, so I inferred there was no solution within the framework of salt.

My workaround has been to abandon the use of a top level tls file since I can’t figure out how to abide by the proper sequencing, and use a bash script to successively call salt to run individual sls files in sequence (tmpl-a-create.sls (in base/dom0) then tmpl-a-configure.sls (on A), then tmpl-b-create.sls (on dom0) and then tmpl-b-configure.sls (on B).

To be perfectly frank, my grasp of salt is within an sls file. I never could figure out how to coordinate between sls files except via a tls (top) file, which of course would just go hog wild as I described above; things in one environment (base) would ignore things going on in another (a VM configuring itself) and not wait for them to finish.

I suppose I could have written salt scripts entirely for base/dom0 and fill them with “qvm run sudo apt install package-x” but what would be the point of using salt at all then.

I will try to encapsulate the menuing issue later–I’m not on my Qubes machine right now and need to do research to make the complaints more specific.

(And I see that Sven has resurrected the old menu thread, so I will do that there.)

7

There are two completely separate questions here:
A. Can I use a single qubesctl call in this case?
No. It’s hard coded in to qubesctl that it will handle states in this
order - dom0, Templates, qubes.
You have to use separate qubesctl calls in this sort of case.

B. Can I make salt state on target A require a state on target B?
This is more difficult in Qubes because we have no master - ordinarily
you would use orchestration or runners to make this happen.
What you can do is make state in A depend on the result of state in
B - you can do this using jinja, by checking the outcome of
the state (e.g. does B have specific feature set?), or by writing pillar
data on completion of state in B, and checking that data in state on A.
There are probably other approaches too, but these are very easy to
implement and work well (for me).

As always, a concrete example would help.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes
8

Actually, your suggestions are probably adequate. I’ll do some experimenting.

And I’m going to have to learn more about pillars. It seems like every doc I read assumes I know what’s already appropriate for that. I really have no notion of what’s in a pillar, only that it seems to work similar to grains…something for me to go investigate. And I was unaware until this moment my sls files could write to a pillar.

(I did recently discover how to set pillar data as a command line parameter to qubesctl…very very handy! I can now write ONE .sls file that contains states to create multiple different VMs, with the ability to select which one happens, via the qubesctl command line. That will cut down on the number of mostly-repetitive create sls files (that differ in name, label, memory size, but not much else) a LOT.)

9

OK

The difference is that grains are information taken from the minion,
whereas pillar data is on the master.
You can indeed write pillar data quite simply, by creating files under
srv/pillar - I do this in the apt-cacher package.
Then you can access that data within a state file using jinja, and use
it in conditionals:

{% if salt['pillar.get']('update_proxy:caching') %}

Absolutely - you can store all this in pillar data, and then pull it in
to a template sls file used to create multiple qubes, again using jinja
to iterate over the pillar.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
10

I was talking about two different things here…and may have been confusing as a result.

  1. I did not know that I could, from within an sls file, write TO a pillar. I already knew how to read FROM a pillar. I still don’t know how to write TO a pillar from within an sls file. (One of your suggestions implied I could write TO a pillar from within an SLS file so that jinja in a different file could check for it.)

  2. I do know that I can put stuff in a pillar on the qubesctl command line or via some other file, BEFORE I run the .sls file.

(Command line is handy; I can write create parameters for dozens of VMs into a jinja table, and use the command line pillar to pick which set of parameters to use; so I have one file that can create any one of dozens of different VMs depending on what I set the pillar to on the command line…that cuts down GREATLY on repetitive SLS files. Even with a jinja include of the actual qvm.clone or qvm.present call (and features and prefs), I still needed separate files to set the jinja variables…until now.)

11

Something like this will do - pulling in predefined files:

# Create pillar for proxy
/srv/pillar/update_proxy/init.sls:
  file.managed:
    - makedirs: True
    - source: salt://cacher/pillar_init.sls
    - user: root
    - group: root
    - mode: 644

/srv/pillar/update_proxy/init.top:
  file.managed:
    - makedirs: True
    - source: salt://cacher/pillar_init.top
    - user: root
    - group: root
    - mode: 644

/srv/pillar/_tops/base/update_proxy.top:
  file.symlink:
    - target: /srv/pillar/update_proxy/init.top

Or, for simple setting data in /srv/pillar/config.sls:

{% if grains['os'] == 'RedHat' %}
terminal_menu: xterm.desktop
{% elif grains['os'] == 'Debian' %}
terminal_menu: debian-xterm.desktop
{% endif %}

new_user: Nergui
I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes
12

OK, that talk of possibly putting all the information needed to create VMs into the pillar had me jump down a very productive rabbit hole. I had previously been using an array defined in Jinja but using salt and pillars lets me do defaults for infrequently-different parameters, which means no need for sparse columns in a Jinja array. It’s not working perfectly yet (largely because of typos) but there it is.

Anyhow the sense I get is that indeed, there’s no way to do what I want in just one qubesctl call, since all dom0 target states will execute first before anything where a template VM is a target does. Which means I’m going to be “stuck” with bash scripts for a while to make the calls in the proper order. However thanks to a lot of recent things I’ve learned, at least those scripts are going to be a lot less complicated!! In any case I’m going to mark comment 7 as the solution.

1 Like