[jsdl-wg] Questions about JSDL specification

[Donal K. Fellows]

Alain Roy wrote:
> JSDL has gone down the route of specifying quite carefully what one can 
> say about a job. (As opposed to something like Condor's ClassAds, which 
> I'm rather partial to. I really do like the idea of allowing users to 
> specify what they want and leave the semantics up to them, not the 
> creators of the language.)

The Condor approach has different problems, namely that is trivial to
produce two systems that cannot interoperate because they use wholly
different vocabularies of terms. That sort of thing is a real problem
for people trying to build higher-level middleware, especially if you
are going to try to translate from other legacy job descriptions. (The
last I heard, there still isn't a standard set of terms for things in
Condor. Without that, how can I possibly know that there is any kind of
correspondence between, say, "CPU" and "Processor"?)

The "nailed down hard"[*] approach has its disadvantages, especially in
the fact that it isn't particularly easy to extend, but it gains in
other ways. At least our schemas are extensible; terms that are truly
missing (e.g., stuff to do with software licenses) can be added without
great trauma.

FWIW, I suspect there isn't a perfect solution to this balance.

> But given that you've specified things so carefully, it was a surprise 
> to me to see something that I couldn't figure out how to interpret as a 
> JSDL consumer.

It's easy to interpret. If someone is so foolish as to specify something
that it is impossible to allocate, throw the job request out on the
grounds of "user error". :-)

The other part of the matching is this: think of the space of resources
available as a set of values, and the content of the IndividualCPUCount
also specifies a set; if the sets have an intersection, you can allocate
the resources as being *any* member of that intersection (and I advise
doing it in such a way as to optimize things from your own perspective
at that point, whatever that means). The aim is that users should
specify what they need to as much detail as they want. If they
over-specify, their choices get restricted but that's their problem.

I'm also working on a spec for a service that will, among other things,
be able to do virtual->concrete resource mapping. Once such things are
added, users can start to ignore how many CPUs are used entirely and
focus instead on important stuff (like "when is the job going to run"
and "how much is the bill going to be"). But that's outside the scope of
the JSDL-WG. :-)

Donal.
[* I suppose it would be more formally correct to describe this as an
    ontological approach, in that it is based on defining a set of terms
    with precise meanings. Indeed, JSDL is certainly stimulating interest
    from the ontologists that I know... ]