action #152101
Updated by mkittler 5 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:** openQA workers within the OSD salt config are properly configured as multi-machine openQA workers even if `WORKER_CLASS=tap_poo1234` or alike ## Suggestions * Read how https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/openqa/openvswitch.sls?ref_type=heads#L38 matches on "tap" in WORKER_CLASS. We commonly disable production tap worker classes with a suffix that include a ticket reference, e.g. "tap_poo1234" * ~~Extend 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. It might still be useful to test that (I only checked the code and used `python3 -i` to see how Python behaves). "tap" * Document that this is how one can ensure a worker is configured for multi-machine tests but not for production jobs