Bug 1313416

Description of problem:

In some (though not rare) cases, a task itself has specific hardware requirements. These can be met, manually, by scheduling the task alone in a recipe, with hostRequires set to whatever the task requires.

However given multiple tasks, a union of the HW requirements needs to be made, to satisfy all tasks - this is fine as long as they don't specify conflicting or unsatisfiable requirements.

However when they do, the tasks need to be split into multiple (as few as possible) non-conflicting "groups" (recipes) based on what's available in the Beaker machine inventory. The issue with doing this externally is that only Beaker has database access to the inventory and can query what machines are available/suitable (and it also already has an API for it).

This RFE tries to propose a more generic approach - to invert the task/recipe XML tag logic, specifying tasks with distro/host requirements within a recipeSet, with Beaker grouping them to recipes (using a scheduler feature) based on common requirements.

As a practical example, consider the following task requirements:

 - testA: < 1GB RAM, < 2 CPU
 - testB: < 2GB RAM
 - testC: (no requirements)
 - testD: > 4GB RAM
 - testE: HVM support
 - testF: > 4GB RAM, < 2 CPU
 - testG: > 1TB HDD

These would be scheduled on (for example, multiple correct solutions)

machine 1: < 1GB RAM, < 2 CPU ; testA,testB
machine 2: > 6GB RAM, > 8 CPU , HVM support, > 1TB HDD ; testC,testD,testE,testG
machine 3: > 4GB RAM, < 2 CPU ; testF


The reason behind special HW requirements might be anything from running an upstream test suite (which requires ie. >1GB RAM) to tests verifying specific hardware functionality (ie. AES-NI).

I understand that this would be a major design decision and am very open to any alternative solutions or proposals.


Version-Release number of selected component (if applicable):
Beaker 22.1