Project

General

Profile

action #107989

CPU-specific worker classes

Added by MDoucha 4 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
Low
Assignee:
Target version:
Start date:
2022-03-08
Due date:
2022-04-22
% Done:

0%

Estimated time:

Description

We have a few tests which require specific CPU types, for example the CPU vulnerability mitigation tests. It'd be useful to have worker classes like x86_64_amd and x86_64_intel so that we can schedule tests on workers which have the required features or vulnerabilities.


Related issues

Related to openQA Project - coordination #14626: [epic] backend and console capabilities interface to increase extensibility and code reuseNew2019-02-17

Related to openQA Project - action #67417: Remote backend capabilityNew2020-05-28

History

#1 Updated by okurz 4 months ago

  • Assignee set to okurz
  • Target version set to Ready

It's a valid idea. You have to be aware that this approach reduces redundancy. We don't necessarily ensure that we have redundant machines for every CPU class. I suggest based on the CPU details which you can find on the workers page of openQA as well add specific worker classes for what you need in particular. Settings need to go into the salt pillars in https://gitlab.suse.de/openqa/salt-pillars-openqa/-/blob/master/openqa/workerconf.sls

EDIT: Discussed in SUSE QE Tools estimation meeting. Future ideas noted down in #65271#note-90

#2 Updated by okurz 4 months ago

  • Related to coordination #14626: [epic] backend and console capabilities interface to increase extensibility and code reuse added

#3 Updated by okurz 4 months ago

#4 Updated by osukup 4 months ago

as short term solution we can add this to salt for real workers ... ( it can be added by salt itself ..)

#5 Updated by okurz 3 months ago

  • Status changed from New to Resolved

osukup wrote:

as short term solution we can add this to salt for real workers ... ( it can be added by salt itself ..)

Yes, but as I stated I don't know the specific requirements so I suggest for users to add specific worker classes.

MDoucha no response by you so closing with our suggestions as resolution.

#6 Updated by MDoucha 3 months ago

okurz wrote:

Yes, but as I stated I don't know the specific requirements so I suggest for users to add specific worker classes.

MDoucha no response by you so closing with our suggestions as resolution.

And I don't know what hardware we have so I can't give you better requirements than "look at the worker list and figure out what might matter for testing". For x86_64, we need extra worker classes at least for Intel and AMD in general. For PowerPC, it might make sense to create extra classes for Power8 and Power9. Anything else can be added later.

#7 Updated by okurz 3 months ago

  • Status changed from Resolved to In Progress

MDoucha wrote:

And I don't know what hardware we have so I can't give you better requirements than "look at the worker list and figure out what might matter for testing". For x86_64, we need extra worker classes at least for Intel and AMD in general. For PowerPC, it might make sense to create extra classes for Power8 and Power9. Anything else can be added later.

That I can do :)

#8 Updated by okurz 3 months ago

  • Due date set to 2022-04-01
  • Status changed from In Progress to Feedback

Hm, I don't know if that makes sense but I created https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/400 which is adding some worker classes. Maybe you mean bare metal machines that use the ipmi backend?

#9 Updated by MDoucha 3 months ago

okurz wrote:

Maybe you mean bare metal machines that use the ipmi backend?

No, I mean all workers. Physical CPU type can still affect test results on QEMU unless you force a specific CPU type emulation via job settings.

#10 Updated by cdywan 3 months ago

MDoucha wrote:

okurz wrote:

Maybe you mean bare metal machines that use the ipmi backend?

No, I mean all workers. Physical CPU type can still affect test results on QEMU unless you force a specific CPU type emulation via job settings.

For the sake of the argument, would it help you if we did configure the emulated CPU explicitly? Not sure if you've tried it before. It should be easy to test out how it affects test runs.

#11 Updated by Xiaojing_liu 3 months ago

okurz wrote:

Hm, I don't know if that makes sense but I created https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/400 which is adding some worker classes. Maybe you mean bare metal machines that use the ipmi backend?

We would like to add CPU info on ipmi backend, such as 64bit-ipmi, intel or 64bit-ipmi,amd. But we don't know get the CPU information of those bare-metal machines.

#13 Updated by okurz 3 months ago

  • Due date deleted (2022-04-01)
  • Status changed from Feedback to Blocked

After finally receiving positive feedback in https://gitlab.suse.de/openqa/salt-pillars-openqa/-/merge_requests/400 from at least one person I now merged :)

Xiaojing_liu wrote:

We would like to add CPU info on ipmi backend, such as 64bit-ipmi, intel or 64bit-ipmi,amd. But we don't know get the CPU information of those bare-metal machines.

As written in https://suse.slack.com/archives/C02CANHLANP/p1648108099104639?thread_ts=1648101936.264619&cid=C02CANHLANP racktables should have all necessary information, if it does not then please raise that as a problem to the managers that managed adding the machines into the racks. For most if not all what e.g. Nick does is only help to get the machines connected, not having access to the invoice or vendor details. You might be able to find out relevant information by looking at previous openQA jobs on the machines finding uploaded logs that include machine details, kernel logs, etc. I created #108842 so maybe we will progress that way but that means that I can effectively block this ticket by #108842 unless anyone wants to go with the alternatives I proposed which I don't plan to do.

#14 Updated by okurz 3 months ago

  • Due date set to 2022-04-22
  • Status changed from Blocked to Feedback

So we have resolved #108842 and clarified that in general SUSE QE Tools will support engineers to get relevant information into racktables and then from racktables also in salt pillar data where necessary.

MDoucha with that back to you, all the necessary information should be available for you to gather information from machines or ask teams to provide the data and then put the according information into salt pillars.

#15 Updated by MDoucha 3 months ago

  • Status changed from Feedback to Resolved

OSD worker list now shows 75 qemu_x86_64 worker instances with WORKER_CLASS=intel and 26 with WORKER_CLASS=amd (out of 156 qemu_x86_64 instances in total). That's good enough for now.

#16 Updated by llzhao 3 months ago

How about the bare metals' work_class?
I have checked the ipmi worker's class there is no intel/amd tag.

#17 Updated by okurz 2 months ago

As written in #107989#note-14 this is up to you to do

Also available in: Atom PDF