[ogsa-rss-wg] Candidate Ordering Language

[Arvid Norberg]

On Aug 7, 2006, at 16:57, Donal K. Fellows wrote:

> Sorry for not getting back to you earlier, but I was on vacation.
>
> Arvid Norberg wrote:
>> The documents those XPath queries are looking in wasn't really
>> discussed. I presume that document is supposed to describe the
>> properties of a particular resource (which is to be ranked).
>
> A Candidate Execution Plan is a document containing a reference to  
> a BES
> container, a JSDL document to submit to that container, and a QoS
> estimate (a place to describe things like the likely cost, delay  
> between
> submit and start, etc.) It might contain other things too (such as a
> suggested CDDLM deployment descriptor or a proposed WS-Agreement
> template) but they're optional (and out of scope too).

I'm not sure If I've misunderstood anything. My impression is that  
the ordering language will rank computing resources (BES containers)  
based on each resource's property (and possibly also QoS properties),  
such as amount of available memory, number of computing nodes, CPUs  
etc. So, some part of the candidate execution plan need to contain  
this information.

(cont. below)

>> The example suggests having a whole jsdl document, which I'm not
>> sure makes alot of sense. There's no Application, file staging
>> or project involved.
>
> In general, the JSDL document might be rewritten as part of the
> candidate generation process. This would allow the original JSDL to
> contain (for example) application-specific extension terms that are
> mapped by the EPS to standard terms understood by the BES container.
> This is an approach I've used with good success in several  
> projects, and
> it's one of the best ways I've seen of coupling the basic service grid
> with higher level application grids.

Yes, I completely agree and appreciate that the jsdl may (and will)  
be modified for each execution plan. In my case for example, I add a  
jsdl-arc:QueueName extension element, in case the resource is running  
ARC.

I still don't see where the actual information about the resource  
itself becomes available to the candidate ordering language. The jsdl  
contains the requirements of the resource it will be submitted to,  
not a specific resource's properties. The CSG uses those requirements  
to match against each of the resource available to it, to filter out  
those that cannot meet those requirements. Is the idea that those  
requirements are replaced by the resource's actual properties by the  
CSG? (that would sound slightly counter-intuitive to me, since it  
would redefine the semantics of the jsdl).

 From the examples you gave of the candidate ordering language:

   <!-- Assume that somewhere there's some JSDL -->
   <value> //JobDescription/Resources/IndividualCPUCount </value>

This looks like the Resources part of the jsdl contains properties of  
the container, and not the requirements of the container. Is that the  
idea?

>
>> The Resources element (from the jsdl spec) on the other hand is
>> (probably) capable of describing all important properties of a
>> resource. It could even contain the name/URL of the BES in
>> Resources/CandidateHosts/HostName.
>
> It can't describe the executable path (which is not equal to the
> application name and version!) arguments, environment variables or
> system limits, all of which are needed for some apps on some  
> platforms.
> Of course, users could figure all that out for themselves, but that's
> just plain stupid as it is forcing them to know about installation-
> specific details even though there is a mechanical selection step  
> in the
> overall process.

I was thinking along the lines that the jsdl for the job was used for  
that, and that the candidate ordering language didn't necessarily  
need access to that info in order to rank a resource (since  
everything in the jsdl are constants anyway, it is already known by  
the one writing the ranking expression, unless the Resources part of  
the jsdl is rewritten).

> Full JSDL documents come back in the Candidate for good reason.  
> It's not
> by whim or wilful misdesign (it would have been nice if it was  
> possible
> to leave it out as that would make the EPS implementations have a much
> higher limit efficiency) but rather a key aspect that has to be there
> for the overall vision to work at all.

I was thinking that what comes back and what is used to describe the  
properties of a resource not necessarily has to be the same thing. Of  
course jsdl documents have to be returned.

Hopefully I've been clear enough of how I'm thinking. You'll have to  
excuse me if I'm misunderstanding something fundamental, I haven't  
been part of any of this and I basically only have access to the  
released drafts on the gridforge site.

--
Arvid Norberg