Need to account for both ppc6le and ppc64el cpu platform names when setting constraints using cpu.platform

[bladernr]

Bug Description

On a recent Power 10 test, I discovered a test had been skipped because the cpu.platform constraint was not met. This was incorrect as it SHOULD have matched and triggered the test to run.:

job cannot be started: resource expression 'cpuinfo.platform in ("ppc64el")' evaluates to false

Looking at the code this is used as a constraint a few times. According to this: https://www.reddit.com/r/qemu_kvm/comments/b6d91v/ppc64el_vs_ppc64le/

they are the same, but it's a debianism to use ppc64el, while it appears IBM has gone with ppc64le on Power systems. I think, in the past on older Power Hardware, ppc64le worked. So to be sure, lets just use both.

This raises the question, can constraints be substring matched? in otherwords, instead of:

cpu.platofrm in ["ppc64el", "ppc64le"]

can we use

cpu.platform = "ppc64*"

to match either of the two?

To Reproduce

1. review this job failure to see the constraint is not met
   https://certification.canonical.com/hardware/202312-32378/submission/347345/test/76846/result/38196711/
2. review the platform info to see that the CPU platform is not the one we've used.
   https://certification.canonical.com/hardware/202312-32378/

Environment

Power 10 LPAR is needed. will have to work with Patricia Domingues in PE to test the fixes.

Relevant log output

No response

Additional context

No response

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/CHECKBOX-1071.

This message was autogenerated

[Hook25]

Sadly no, this can't be done right now. The == in the resource expression is an actual python ==, so there is no way to use globs there.

I have for you three solutions:

1. in as you suggested does the job that you need but it is cumbersome (you need to remeber to put it everywhere)
2. create an additional field to the cpuinfo resource that provides the "platform_id" or "platform_family" (TODO: find a better name here, I'm not sure how to call it) that would be ppc64 in this case. This is nice because it groups them "by default", while still retaining the fact that they report a different name
3. collapse the two into the same name in the resource "ppc64", loosing the tail, or "ppc64el", renaming the other. This does hide the fact that the machine reports a different name, but should be way clearer for the reader what you are trying to do with the resource expression

What do you think? I'm leaning a bit toward 3.