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... ]