Project

General

Profile

Actions

action #63766

closed

Handle HDD* vars in generalhw backend

Added by ggardet_arm about 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
2020-02-24
Due date:
% Done:

0%

Estimated time:

Description

Currently, vars in /etc/openqa/workers.ini are not expanded, so, for example, you cannot use %HDD_1% in other variables.

My use case is for generalhw backend used with System-Under-Test (SUT), here Raspberry Pi 3 boards.
If you have an openQA MACHINE (e.g. RPi3) matching a single openQA worker, you can define all the required vars in MACHINE.
But to scale, we need an openQA MACHINE which matches multiple openQA workers, with each worker limited to a single SUT (worker 1 => Raspberry Pi 3 board number 1, etc.) and you need to define things in the worker config (main vars are IP related).
So, for now, we cannot use %HDD_1%, FLASHER_IP or SUT_IP variables in /etc/openqa/workers.ini and cannot have something like GENERAL_HW_FLASH_ARGS = /var/lib/openqa/factory/hdd/%HDD_1% %FLASHER_IP%:/tmp/
For the IPs, it could be workarounded with copy/paste as it will not be changed from one run to another, but %HDD_1% will change with each test.

Actions #1

Updated by ggardet_arm about 4 years ago

This could be handled in generalhw.pm, but it does not sound very good.
The expansion should probably be run on worker.ini file with openQA.

Actions #2

Updated by coolo about 4 years ago

We could report the variables from workers.ini on registering it. Expanding in the worker I consider a no-go

Actions #3

Updated by okurz about 4 years ago

  • Subject changed from vars in /etc/openqa/workers.ini are not expanded to support for variable expansion in /etc/openqa/workers.ini
  • Category set to Feature requests

With %HDD_1% expected to come from the test triggering point. Why not handle any dynamic logic in os-autoinst:backend/generalhw.pm ? At this point we have read out all information from openQA as well as the openQA worker and IMHO the command can be put together in os-autoinst scope from all necessary information in vars.json. I would not use the "%VAR%" format from openQA for this though. It's basically the same as we do for other backends, the qemu command line that we put together from all different variables.

Actions #4

Updated by coolo about 4 years ago

this drops all connection to the asset though - you only get a connection if openQA (and not os-autoinst) knows the value of HDD_1

Actions #5

Updated by ggardet_arm about 4 years ago

  • Category deleted (Feature requests)
  • Assignee set to ggardet_arm

HDD_1 handling will be fixed by https://github.com/os-autoinst/os-autoinst/pull/1356
IP addresses can just be copied/pasted.

Actions #6

Updated by okurz about 4 years ago

PR has been merged. Can we agree that "variable expansion in /etc/openqa/workers.ini" as phrased here is therefore not the way we want to go?

Actions #7

Updated by ggardet_arm about 4 years ago

  • Subject changed from support for variable expansion in /etc/openqa/workers.ini to Handle HDD* vars in generalhw backend
  • Status changed from New to Resolved

okurz wrote:

PR has been merged. Can we agree that "variable expansion in /etc/openqa/workers.ini" as phrased here is therefore not the way we want to go?

That's right. I changed it to: "Handle HDD* vars in generalhw backend"

Actions

Also available in: Atom PDF