On 01/02/2013 12:57 PM, Raymond Mancy wrote:
I'd be curious to see what kind of preferences we're talking
When it comes to resources used, this would make more sense
on a shared system, where the recipe is running in the background
on a system that is performing other concurrent work. In such a case the system owner
describing their preferences such as memory, disk space and CPU usage makes sense. In
though nothing else is running on a system, so resource usage is a non issue to the
It does make sense to have the recipe run time as a preference (perhaps owners may want
to infrequently take
control of their machine and do not want to accept recipes that run for a week),
but the problem is that we allow recipe owners to dynamically change the run time of a
I guess group/user based preferences make the most sense. The owner may give favour to
over others, which is perfectly legitimate.
Yep, the focus is user/group preferences. We want to make it easier for
a system owner to say "If any of my team have jobs in the queue, run
those, otherwise run someone else's job". At the moment, system owners
that want to prioritise their own team's jobs effectively have to opt
out of contributing to the public pool at all.
The flipside is finally exposing the owner/group/public pool preference
in recipe definitions and the user preferences - that one will apply
when the recipe is first checked against the pool of idle systems (if
there's no appropriate system available immediately, the recipe will
enter the queue and be assigned to the first system that wants to run it).
It wouldn't surprise me if we eventually go down the Condor path of
allowing system owners to prefer jobs that make better use of a
machine's capabilities, but there are plenty of things ahead of that on
the to-do list.
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (http://beaker-project.org/
GlobalSync Development Lead (http://pulpdist.readthedocs.org