Excerpts from Dan Callaghan's message of Fri Jan 06 09:41:41 +1000 2012:
Excerpts from Steven Lawrance's message of Fri Jan 06 08:48:35 +1000 2012:
So if we can't distinguish not being able to provision a particular recipe via RHEV "right now" as opposed to "never (with current resources)", then we at least need a cheap way to determine the former in order to avoid a bottleneck in the scheduler.
That is, when a job is submitted, we want to determine whether it _can_ be satisfied by RHEV without then restricting it to RHEV and preventing it from going to baremetal hardware in the lab.
Does Beaker even need to care about the difference between "right now" and "never"? If a recipe can't be provisioned by RHEV "right now", whether because RHEV's resources are temporarily exhausted or the recipe could never fit, shouldn't Beaker then try to provision it on real hardware immediately?
Yes it should, but what if the real hardware resources are also exhausted...
Otherwise we could end up with recipes queued waiting for RHEV while real hardware sits idle.
Right, so we can't decide at submission time whether the recipe _is_ going to be provisioned via RHEV, only whether it _can_.
Bill's concern is the time spent polling RHEV to check whether it has the resources, on top of the existing SQL query for "real" systems, once for each queued recipe, on each iteration of the loop (currently every 20 seconds).
Steven.