I found out how to readily set grains…and in this case I think grains are appropriate.
some-state-name:
grains.present:
- name: new_grain
- value: new_value
I can run this state and qubesctl grains.ls and qubesctl grains.items issued from dom0 will show it as present. Furthermore it seems to be visible in dom0-targeted sls files.
However, this will simply not show up in an domU targeted file. One grain that does work there is ‘nodename’.
Thinking this was somehow an issue with grains I set, I looked for ‘productname’ with both grains[‘productname’] and salt’grains.get’. Jinja simply throws up at the first one, while the second “works” (if returning an empty value instead of the productname you expect is “working”)
Next: I tried setting the grain within the sls file run on the target. It seems to have actually done something; it says it created the grain…but I can’t read it later on in the same sls file. (The grain also does not appear in dom0 with grains.ls or grains.items.)
I’m concluding that a state run on a vm (other than dom0) for some reason can’t see most of the grains that appear to be visible to dom0. So now I’d like to know how to make grains I set vislble.
Between that and the inevitable ten to twelve runs I have to do to get past f*cking jinja syntax errors I’ve now spent three hours trying to do what should be a fairly simply task: Execute a state in an sls file only one one of the two machines I own. It would be simple, if I could only “see” the productname or better yet, a grain I defined based on the productname.
I’m probably going to have to write a file full of jinja variable “sets” and include it in my sls files…I can autogenerate that in dom0; heck I am autogenerating my grains values in a dom0 state file.
[BTW, when jinja fails to parse a file, why does it return “OK”? Likewise with salt itself. I have to read the log file every time…both when it says it’s OK and when it says there’s an error, just to be sure an OK result isn’t the biggest damn lie my computer tells me.]