HW requirements, `and`, `or` and expected outcome

[happz]

Imagine following provision.hardware setup:

hardware:
  or:
    - disk:
        - size: >= 20 GiB
        - size: >= 512 GiB
        - size: >= 512 GiB
    - disk:
        - size: >= 20 GiB
        - size: >= 1024 GiB

Some provisioning services, like OpenStack and AWS, come with instance types that have a relatively rigid root disk set up, but besides that one, it's possible to create additional "disks" with quite a precise size, and a number of these additional volumes can go to low tens. There are also provisioners like Vagrant that support even more freedom, but the principle is the same, it's easy to add more volumes with their size and type under control.

It is, therefore, possible to satisfy both branches of hardware.or directive from the example above, with the comparable amount of work - both would use the same instance type, providing the root disk, with an additional volume or two, respectively. Which one of these would you expect to be the final answer? Is there some order of precedence that should be followed?

Also, it's possible to construct constraints like this one:

hardware:
  or:
    - disk:
        - size: >= 20 GiB
        - size: >= 512 GiB
        - size: >= 512 GiB
    - disk:
        - size: >= 20 GiB
        - size: >= 1024 GiB
    - cpu:
          model: 6

A reduced list of suitable instance types would consist of both types that can hold additional volumes, but also instance types that cannot but do have matching CPU. What would be your expectation in this case?

• For example, should less work be the rule here, picking virtually any instance type with cpu.model == 6, rather than those that can hold additional volumes, and avoid "wasting" time creating those volumes?
• Or some kind of "resource usage" weight to be applied, picking an instance type that uses the lowest amount of resources (2 volumes vs 3 volumes, but with the same combined size, or an instance type with just the root disk and matching CPU)?
• Also, how about "any of the matching types is a valid answer"? I guess it could be argued that all matching instance types are valid, provisioning is then free to pick one, no questions asked, and if the user is surprised by the final VM setup, it's their fault and they should refine the content of hardware in their plan.

I admit, both examples are slightly on the extreme side of things, but having clear guidelines for these situations would help a lot.

[happz]

This one's even better:

or:
  - disk:
      - size: >= 20 GiB
      - size: >= 512 GiB
  - disk:
      - size: >= 20 GiB
      - size: <= 511 GiB

In theory, we can create a VM for each of the branches, one with the second volume of 512 GB, one with the second volume of 511 GB. The question is, which one to provision? :)

I wonder what would Beaker do, with a similar XML. Probably gathering all matching machines, then (randomly) picking one.

[psss]

It seems there was no clear outcome here. @happz, is this something we want/need to make clear before merging the hardware helpers?

[happz]

It seems there was no clear outcome here. @happz, is this something we want/need to make clear before merging the hardware helpers?

It's not necessary to resolve before merging the first PR, but clear guidance for both provision plugin developers and users would be nice to have. As of now, Artemis works in the "any of the matching types is a valid answer" mode, it might try to pick the smallest possible instance type, but that's all.

[psss]

Decision: If there are multiple options available, tmt should choose the first one (preferred most by the user).