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.