action #160652
Updated by okurz 26 days ago
## Motivation
We had qesapworkers disabled due to MM-test issues.
As part of #152389 "tap" was disabled from qesapworkers. What changed since then is that #152389 was erroneously resolved without completing the rollback steps mentioned in #152389#Rollback-steps while still keeping the tap classes disabled referencing then closed #152389. It's worth to re-enable those machines (multiple, not one) to have "tap" to have a simpler and consistent configuration where multi-machine support is enabled by default and not an exception. Also since then we better handle islands of multi-machine enabled workers depending on region/datacenter/location so can we use that? No, we can't because we also would need to teach the openQA scheduler to only schedule within one zone.
That's more related to #160646 about other machines, fixed meanwhile. This ticket here was only about qesapworkers in particular while there are multiple other machines providing "tap" already
## Acceptance criteria
* **AC1:** https://gitlab.suse.de/openqa/salt-pillars-openqa/-/blob/master/openqa/workerconf.sls has no mention of "tap_poo152389" anymore
* **AC2:** We can still explicitly schedule multi-machine tests on those workers
## Suggestions
* As the openQA scheduler currently would schedule covering multiple locations which would lead to problems we should not add the tap class to machines in PRG1. Similarly for NUE2 based machines we removed the "tap" class completely. So we should simply remove the tap_poo152389 worker class here as well. Or use "tap_secondary" and explain "tap_secondary" in the README where we describe worker classes
Back