The primary reason for passing the job requirements to the local batch
system is so that the scheduler and make intelligent (presumably
efficient) decisions.
> 1) Keep the current syntax, allow matching against multiple subclusters,
> and pass the subcluster name to the batch system.
This is not a solution to the problem. It only allows classes of jobs
to be identified but no intelligent scheduling within those classes can
be done. This is exactly the problem we have now except that you've got
slightly finer granularity than using just queues.
> 2) Build a classad parser which does the best it can with the expression
> it gets; that parser might be either in the WMS or in the CE.
>
> 2a) As 2, but insist that users restrict their requirement expressions
> to things the parser can deal with.
>
> 3) Add new things in the JDL which match more directly with the kind of
> thing you get in batch systems, e.g.:
>
> CPULimit = 3600;
> MEMlimit = 511;
> DiskLimit = 500;
> Priority = 3;
>
> 3) is simpler on the batch system side, but you still have to adapt it
> to specific systems, you still have to make it match the glue schema (or
> vice versa), and you lose a lot of the potential richness of the classad
> expressions.
I would instead opt for a hybrid approach of 2) and 3). Allow people to
define parameters like in 3) and have whatever processes the final JDL
combine those with any explicit requirements to arrive at the full
expression. Only those limits given separately would be passed to the
local batch system. This makes it easy to parse, loses none of the
functionality of the classad, and could be implemented in a finite
amount of time. It is also closer to the spirit of the GGF job
description.
Cal
|