QA » openQA Project » openQA Infrastructure

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 of multihostclass 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 contains tap 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