action #135005
openopenQA Project (public) - coordination #112862: [saga][epic] Future ideas for easy multi-machine handling: MM-tests as first-class citizens
openQA Project (public) - coordination #111929: [epic] Stable multi-machine tests covering multiple physical workers
Reduce duplication in salt-pillars-openqa openqa/workerconf.sls with advanced YAML/jinja features
0%
Description
Motivation¶
See https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/582#note_530351
sls files for Salt are Jinja templates. After jinja processing they result in YAML files, and only then can be checked for the correct YAML syntax.
That means we cannot just use a linter on those files in merge requests.
The files can grow quite large, so it's hard to manually review if the YAML would look actually correct. Using aliases and merge keys (<<) could help reducing the size, but checking aliases manually close to impossible, because you have to keep track of where they are created (anchors) and used, and if there is no typo.
A linter can do that. However there seems to be no way to run salt in a dry mode to automatically test all possible jinja values.
Suggestions¶
- How about trying to fill in example values for jinja processing and then check the resulting YAML?
Updated by okurz over 1 year ago
- Related to action #116845: salt-states-openqa CI complains about "fatal: Authentication failed for 'https://gitlab.suse.de/openqa/salt-pillars-openqa/'" but no useful hint size:M added
Updated by okurz over 1 year ago
A little bit of background. In #115553 we introduced a fully mocked pillars repo. With that we also don't implicitly test anymore the pillars repo content. In before we simulated being worker3 or something and at least read a bit of openqa/workerconf.sls for validity checking purposes. We can now consider to introduce more salt test checks in the pillar repo by cloning the latest master salt states repo and running a tested high state with a pillars definition in each merge request.