action #66676
closed
Add `qemu_aarch32` to WORKER_CLASS for openqa-aarch64 machine
Added by ggardet_arm almost 4 years ago.
Updated almost 4 years ago.
Description
Currently, WORKER_CLASS for openqa-aarch64 machine is set to qemu_aarch64.
It was fine so far since openQA aarch32* machines uses WORKER_CLASS=qemu_aarch64. But all aarch64 machines are not 32-bit capable, so we need need to distinguish them.
So, we need to add qemu_aarch32 to the list of supported WORKER_CLASS for openqa-aarch64 machine.
Once done, we can update aarch32* machines to use WORKER_CLASS=qemu_aarch32.
These workers don't use salt so I suppose one simply needs to change the config.
But all aarch64 machines are not 32-bit capable, so we need need to distinguish them.
So which machines exactly are capable and need the worker class qemu_aarch32 added?
mkittler wrote:
These workers don't use salt so I suppose one simply needs to change the config.
But all aarch64 machines are not 32-bit capable, so we need need to distinguish them.
So which machines exactly are capable and need the worker class qemu_aarch32 added?
openqa-aarch64 (D05 with Cortex-A72) was the only system on o3 until very recently and it does support 32-bit.
I added some remote workers running on:
- a ThunderX2 which is not capable of aarch32
- a HoneyComb (Cortex-A72) which is 32-bit capable and already includes this tag.
- an AWS A1 instance (Cortex-A72), which is 32-bit capable and already includes this tag.
- Raspberry Pi 2 and 3 (based on the generalhw backend, not on qemu, so out of scope here)
- Status changed from New to Feedback
- Assignee set to mkittler
- Target version set to Current Sprint
Ok, I've changed the config on openqa-aarch64 to include qemu_aarch32. It will be used after the next reboot (or manual service restart). Since you've already taken care of the other machines I guess that's it.
- Status changed from Feedback to Resolved
I updated aarch32* machines on o3 to use WORKER_CLASS=qemu_aarch32.
Also available in: Atom
PDF