Introduce a new L1 test attribute 'hardware'

[sopos]

There should be a way to specify test's (L1) requirements for the HW, similarly to [1].

I propose test's attribute hardware with basically the same properties as described in [1].

In particular:

hardware:
    # Basic key-value format used to specify the memory size
    memory: 8 GB

    # Processor-related stuff grouped together
    cpu:
        processors: 2
        cores: 16
        model: 37

      # Disk group used to allow possible future extensions
    disk:
        space: 500 GB

    # Optional operators at the start of the value
    memory: '> 8 GB'
    memory: '>= 8 GB'
    memory: '< 8 GB'
    memory: '<= 8 GB'

    # By default exact value expected, these are equivalent:
    cpu:
        model: 37
    cpu:
        model: '= 37'

    # Enable regular expression search
    cpu:
        model_name: =~ .*AMD.*

    # Using advanced logic operators
    and:
      - cpu:
            family: 15
      - or:
          - cpu:
                model: 65
          - cpu:
                model: 67
          - cpu:
                model: 69

1. https://tmt.readthedocs.io/en/stable/spec/plans.html#hardware

[sopos]

There's also a need for HW virtualization. This could be handled by a separate platform attribute or a cpu property.
Currently I can think of two ways to express this.

hardware:
    cpu:
        virtualization: true

hardware:
    capabilities:
      - virtualization

[psss]

So the hardware requirements would be gathered from individual tests and then subplans created for each hardware-compatible group as proposed in #308? It would make sense to me to keep the L1 and L2 specification for hardware requirements identical. @thrix, @happz, any thoughts or recommendations about this?

[psss]

Both outlined options for hardware virtualization requirement seem good to me. @sopos, which other capabilities could be possibly provided in the section in the future? Are there any tangible examples?

[sopos]

Both outlined options for hardware virtualization requirement seem good to me. @sopos, which other capabilities could be possibly provided in the section in the future? Are there any tangible examples?

I do not have anything else to provide as an example. It just came to my mind when I was thinking of the best place for such information. As specifically virtualization is basically a property of a CPU but it may be considered as a property of a machine as well.

[sopos]

Actually, what about presence of a TPM chip, it may be considered as a capability as well. And we have tests which need the TPM.

I would say it also depends on the way how the HW inventory presents such things. But we should be independent on the HW provisioners and their ways of presenting the properties. We should use an abstract form wich would be translated to e.g. beaker, openshift, libvirt, ...

[thrix]

+1 on making it identical, of course I believe we should first land the plan support, following with the test support later on, as that will require a lot more changes? Are this subplans already something working?

[happz]

+1 for keeping L1 and L2 specifications virtually the same.

As the relationship between L1 and L2 goes, I'd expect - naively... - some sort of inheritance, e.g. when executing a plan, tmt should probably collect L1 requirements, spawning either one plan to satisfy all or several plans for each L1 set incompatible with other requirements. I would like to avoid copy-pasting L1 requirements to L2, or merging them manually. But I suppose that's out of the scope of this particular issue - L1 hardware should be a thing no matter how the actual L1/L2 workflow would look in the future.

I'd just recommend keeping the addition of the virtualization flag for a stand-alone patch. BTW what kind of virtualization is this flag for, an environment that is capable of virtualization, or an environment that is - or better is not - virtualized itself (aka "I need a bare-metal machine")?

[psss]

Are this subplans already something working?

No, for now the idea is only outlined in #308. But we would like to implement soon the first step in this direction: Splitting a single plan into multiple plans each cotaining a single test, which is basically something like wow --slice 1.

[sopos]

I'd just recommend keeping the addition of the virtualization flag for a stand-alone patch. BTW what kind of virtualization is this flag for, an environment that is capable of virtualization, or an environment that is - or better is not - virtualized itself (aka "I need a bare-metal machine")?

Good question. I kind of hoped that I made it self-explanatory. We may need to make it better. :-)

The intention is to specify a need of the virtualization feature. E.g. I want to spin up some VMs as a part of a test.
If I request a machine with cpu: {virtualization:true} I'm basically asking for a machine where the CPU allows me to do so. With the capability: [virtualization] it may be more obvious that I need a HW capable of virtualization.

But actually, to express a need for virtualized machine one could define something like capability: [virtualized]. This could be useful mainly in kernel team where they need to run tests on bare metal as well as in virtualized env.

Finally, I may require capabilities: [virtualization, virtualized] which would basically say I want a VM with nested virtualiyation turned on.

To allow also negative requirement it might not be a list but a list of dicts:

hardware:
    capabilities:
      - virtualization: false
      - virtualized: true

Meaning give me a VM with nested virtualization turned off.

[happz]

I suppose this follow-up discussion deserves its own issue, but since we already started...

Just a few thoughts while looking at Beaker as an example, the "need bare-metal" request can be specified with Beaker XML in this way:

VIRT__BAREMETAL                                 <system><hypervisor op="==" value="" /></system>
VIRT__KVM                                       <system><hypervisor op="==" value="KVM" /></system>
VIRT__XEN                                       <system><hypervisor op="==" value="Xen" /></system>
VIRT__POWERKVM                                  <system><hypervisor op="==" value="PowerKVM" /></system>
VIRT__POWERVM                                   <system><hypervisor op="==" value="PowerVM" /></system>
VIRT__HYPERV                                    <system><hypervisor op="==" value="HyperV" /></system>
VIRT__VMWARE                                    <system><hypervisor op="==" value="VMWare" /></system>

Seems like the provisioning plugins and the whole HW area should be aware of the "hypervisor" property of the environments they can provide, which makes sense, and they really should be aware of this kind of property. Supporting a yes/no "shortcut" - as a user, I really dislike "magic" values like "empty hypervisor means bare-metal, you silly sausage", therefore is-virtualized key in HW requirements is very welcome, to shield me from this kind of details.

I'd still like to be able to test the hypervisor property on its own, but to find out whether it's "none" vs. "any"? Nah, rather give me is-virtualized flag.

The "need virtualization" request is handled like this:

MACHINE_SET__VIRT_SUPPORT  <and><key_value key="HVM" op="=" value="1"/><memory op="&gt;" value="2047"/><diskspace op="&gt;" value="19999"/><system_type value="Machine"/></and>

Seems to contain some additional filters, but depends on one machine property known to Beaker. Maybe there are other implementations (well, I'm pretty sure there must be), so I'd stay clear from supporting {capabilities: {hvm: true}} as means of requesting virtualization support.

I like the capabilities idea, it should work well in grouping this kind of request, things that could be queried in another way, but with more work or not fully. For example, I suppose I could construct a request:

and:
  - hypervisor: "!= kvm"
  - hypervisor: "!= xen"
  # and so on...

but I find that quite repulsive, it'd hardly be complete... So, yes:

capabilities:
  is-virtualized: true|false

looks better to me. Maybe we could define the hypervisor right away when adding the virtualization part, so people could do this:

capabilities:
  is-virtualized: true
hypervisor: "!= xen"

My point is that since the provisioning should be aware of whether the environment is virtualized or not, knowing how is this achieved and what moving pieces are in play should naturally be part of that understanding.

(Disclaimer: bikeshedding...): I'm not sure which of these would be better:

arch: x86_64
capabilities:
  is-virtualized: true
  virtualization: true

# or

arch: x86_64
is-virtualized: true
virtualization: true

After all, all those flags are some sort of capabilities... One of them is real, the other is some reflection or extract of other capabilities and/or properties. I suppose we could argue in favor of both, it's very, very hard to decide, aargh! :)

[psss]

After all, all those flags are some sort of capabilities... One of them is real, the other is some reflection or extract of other capabilities and/or properties. I suppose we could argue in favor of both, it's very, very hard to decide, aargh! :)

Yeah, both approaches seem to be valid and... fine. On the other hand, not completely sure that is-virtualized is actually a capability at all. Perhaps feature would be general enough to embrace all kinds of properties and capabilities and... features?

Or we can just forget about the extra level. Let's finalize the discussion about these two keys in the #895 pull request.

[snits]

Is there a list of what hardware can be specified? Also is there any idea of what is going to be used for system inventory (beaker-system-scan, or something else)? I'd like to see the inventory tool do a better job of identifying systems that have an iommu/smmu.