Project

General

Profile

Actions
Copy link

action #169492

open

per worker-class settings in salt states size:S

Added by szarate about 1 month ago. Updated about 1 month ago.

Status:
Workable
Priority:
Normal
Assignee:
-
Category:
Feature requests
Target version:
QA (public) - Tools - Next
Start date:
2024-11-07
Due date:
% Done:

0%

Estimated time:

Description

Motivation

We want worker-class specific settings which we can specify in workers.ini. That should be configurable with salt, e.g. in https://gitlab.suse.de/openqa/salt-states-openqa, but should use a new upstream openQA feature parsing a new to be designed syntax in workers.ini

Acceptance criteria

  • AC1: worker-class specific settings can be specified in workers.ini

Suggestions

Allow additional sections like [class:tap] in workers.ini. The config parser of the worker would go though the list of classes and consider all settings of matching classes as well. The instance-specific settings in the numbered sections would still have precedence of course.

Further details

See conversation at: https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/924#note_685345

Original motivation

I think the salt states need a way to apply certain settings to workers with different values, depending on the class:

One example is of poo#168097, where it would be great to be able to set a variable to be applied to all workers, like REPO_MIRROR_HOST with an overriden default, per class: 

location-nue3:
  - REPO_MIRROR_HOST=https://nue3.example.com
location-lab:
  - REPO_MIRROR_HOST=https://lab.example.com

And have these settings applied to all workers, with said class.

Not sure if this should happen at the level of whatever manages the workers, or code in openQA

Actions
Copy link
 #1

Updated by okurz about 1 month ago

  • Project changed from openQA Infrastructure (public) to openQA Project (public)
  • Category set to Feature requests
  • Target version set to Tools - Next

I think it would be neat if that is done on the level of openQA worker itself

Actions
Copy link
 #2

Updated by mkittler about 1 month ago · Edited

Yes, e.g. by allowing additional sections like [class:tap] in workers.ini. The config parser of the worker would go though the list of classes and consider all settings of matching classes as well. The instance-specific settings in the numbered sections would still have precedence of course.

This would help to simplify my local workers.ini a lot as many settings are actually related to a class.

Actions
Copy link
 #3

Updated by okurz about 1 month ago

mkittler wrote in #note-2:

This would help to simplify my local workers.ini a lot as many settings are actually related to a class.

maybe you can show a diff of your workers.ini or an abstracted example of how it would look like before and after the hypothetical change?

Actions
Copy link
 #4

Updated by mkittler about 1 month ago

The redundancy in lots of instance configurations could be reduced. So

[11]
BACKEND = svirt
WORKER_CLASS = svirt-vmware
VIRSH_HOSTNAME=127.0.0.1
VIRSH_USERNAME=root
#VIRSH_PASSWORD=
VIRSH_CMDLINE=ifcfg=dhcp
VIRSH_INSTANCE=9
VMWARE_HOST=…
VMWARE_PASSWORD=…

[12]
BACKEND = svirt
WORKER_CLASS = svirt-vmware
VIRSH_HOSTNAME=127.0.0.1
VIRSH_USERNAME=root
#VIRSH_PASSWORD=
VIRSH_CMDLINE=ifcfg=dhcp
VIRSH_INSTANCE=10
VMWARE_HOST=…
VMWARE_PASSWORD=…

could become:

[11]
WORKER_CLASS = svirt-vmware
VIRSH_INSTANCE=9
VMWARE_HOST=…
VMWARE_PASSWORD=…

[12]
WORKER_CLASS = svirt-vmware
VIRSH_INSTANCE=10
VMWARE_HOST=…
VMWARE_PASSWORD=…

[class:svrit-vmware]
BACKEND = svirt
VIRSH_HOSTNAME=127.0.0.1
VIRSH_USERNAME=root
VIRSH_PASSWORD=…
VIRSH_CMDLINE=ifcfg=dhcp
Actions
Copy link
 #5

Updated by livdywan about 1 month ago

  • Subject changed from per worker-class settings in salt states to per worker-class settings in salt states size:S
  • Description updated (diff)
  • Status changed from New to Workable
Actions
Copy link

Also available in: Atom PDF