action #152101
Updated by okurz 4 months ago
## Motivation
See lessons learned meeting #139136. Would diesel now work with the MTU related changes? Yes, we should test that. We should first ensure that diesel is treated as tap worker regardless of not being used as production tap-worker. Relax https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/openqa/openvswitch.sls?ref_type=heads#L38 to also match on "tap_poo1234" and document that this is how one can ensure a worker is configured for multi-machine tests but not for production jobs
## Acceptance criteria
* **AC1:** non-production openQA workers within the OSD salt config are properly configured as multi-machine openQA workers with suffixes e.g. even if `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 or alike
## Suggestions
* Read how https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/openqa/openvswitch.sls?ref_type=heads#L24 https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/openqa/openvswitch.sls?ref_type=heads#L38 matches on "tap" in WORKER_CLASS. We used to commonly disable production tap worker classes by adding with 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 It might still be useful to test that currently have "tap_$something", (I only checked the code and used `python3 -i` to 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 how Python behaves).
* 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
Back