Project

General

Profile

Actions

action #135005

open

Reduce duplication in salt-pillars-openqa openqa/workerconf.sls with advanced YAML/jinja features

Added by okurz 8 months ago. Updated 8 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
2023-09-01
Due date:
% Done:

0%

Estimated time:
Tags:

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?

Related issues 1 (0 open1 closed)

Related to openQA Infrastructure - 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:MResolvedmkittler2022-09-20

Actions
Actions #1

Updated by tinita 8 months ago

  • Description updated (diff)
Actions #2

Updated by tinita 8 months ago

  • Description updated (diff)
Actions #3

Updated by okurz 8 months 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
Actions #4

Updated by okurz 8 months 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.

Actions

Also available in: Atom PDF