Project

General

Profile

Actions

action #152101

closed

openQA 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

Added by okurz 11 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
-
Target version:
Start date:
2023-12-05
Due date:
% Done:

0%

Estimated time:
Tags:

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 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

Related issues 1 (1 open0 closed)

Copied from openQA Infrastructure - action #152098: [research][timeboxed:10h] Learn more about openvswitch with experimenting together size:SWorkable2023-12-05

Actions
Actions #1

Updated by okurz 11 months ago

  • Copied from action #152098: [research][timeboxed:10h] Learn more about openvswitch with experimenting together size:S added
Actions #2

Updated by mkittler 11 months ago

  • Description updated (diff)

I had a look at the code anyways so I edited the suggestion.

Actions #3

Updated by okurz 10 months ago

  • Target version changed from Tools - Next to Ready
Actions #4

Updated by okurz 10 months ago

  • Priority changed from Normal to Low
Actions #5

Updated by okurz 10 months ago

  • Subject changed from Allow salt to properly configure non-production multi-machine workers to Allow salt to properly configure non-production multi-machine workers size:M
  • Description updated (diff)
  • Status changed from New to Workable
Actions #6

Updated by mkittler 7 months ago

  • Assignee set to mkittler
Actions #7

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.

Actions #8

Updated by mkittler 7 months ago

  • Status changed from Feedback to Resolved

The MR was merged so all ACs are fulfilled.

Actions

Also available in: Atom PDF