action #152101
closedopenQA Project - coordination #112862: [saga][epic] Future ideas for easy multi-machine handling: MM-tests as first-class citizens
openQA Project - coordination #111929: [epic] Stable multi-machine tests covering multiple physical workers
Allow salt to properly configure non-production multi-machine workers size:M
0%
Description
Motivation¶
See lessons learned meeting #139136. Would diesel now work with the MTU related changes? We should ensure that diesel is treated as tap worker regardless of not being used as production tap-worker.
Acceptance criteria¶
- AC1: non-production workers within the OSD salt config are properly configured as multi-machine openQA workers with suffixes e.g.
WORKER_CLASS=tap_poo1234
(no GRE tunnels required) - AC2: non-production openQA workers with a special worker class can execute multi-machine jobs correctly if triggered against the special worker class
- AC3: non-production openQA workers with a special worker class do not pick up production multi-machine jobs
- AC4: The team knows how to configure non-production multi-machine workers for development/setup/debugging
Suggestions¶
- Read how https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/openqa/openvswitch.sls?ref_type=heads#L24 matches on "tap" in WORKER_CLASS. We used to disable production tap worker classes by adding a suffix that include a ticket reference, e.g. "tap_poo1234"
Extend that to be able to match on variants of "tap"It will still work with e.g. "tap_poo1234". The last part ofmultihostclass in pillar['workerconf'][host]['workers'][wnum]['WORKER_CLASS']
refers to a string (and not a list) so Python does in fact just check whether the string containstap
at all.- Take a look at OSD workers that currently have "tap_$something", see https://gitlab.suse.de/openqa/salt-pillars-openqa/-/blob/master/openqa/workerconf.sls, e.g. qesapworker-prg4 or diesel, and verify that those workers can still execute multi-machine clusters if scheduled against those specific classes
- Document that this is how one can ensure a worker is configured for multi-machine tests but not for production jobs
Out of scope¶
- We don't strictly care about GRE tunnels here
Updated by okurz 11 months ago
- Copied from action #152098: [research][timeboxed:10h] Learn more about openvswitch with experimenting together size:S added
Updated by mkittler 7 months ago
- Status changed from Workable to Feedback
It looks like our salt states already fulfill AC1 (but GRE tunnels in indeed not being configured¹). That means also means AC2 and AC3 are fulfilled. I created https://gitlab.suse.de/openqa/salt-states-openqa/-/merge_requests/1149 for AC4.
¹ But that's also a good thing as we probably don't want non-production-ready machines to interfere with the rest of the machines.