Hi; I agree with Karl's later email pointing out that it would be really unfortunate if we end up with two separate specifications to describe the two closely intertwined topics of job requirements and (available) resource descriptions. From a resource description point-of-view, I agree that a simple approach based on a set of jsdl documents would represent an interesting simple approach. If we structure things so that alternative approaches can be transparently substituted -- e.g. by having resource description infosets have a top-level element that describes which description approach they're taking -- then we can get started without having to either solve all the problems of a fully general solution or foreclose more general solutions as they get defined later on. Marvin. -----Original Message----- From: Donal K. Fellows [mailto:donal.k.fellows@manchester.ac.uk] Sent: Tuesday, June 06, 2006 2:07 AM To: Peter Lane Cc: Marvin Theimer; ogsa-bes-wg@ggf.org; Ed Lassettre Subject: Re: [ogsa-bes-wg] Questions and potential changes to BES, as seen from HPC Profile point-of-view Peter Lane wrote:
Marvin Theimer wrote:
* JSDL seems to inherently be focused on describing a single job or a single computational resource. For example, it has no notion of describing all the differing compute nodes of a (heterogeneous) compute cluster. By incorporating JSDL elements into the BES information model it seems that BES is foreclosing the ability to describe things like compute clusters. This issue also effects what can get returned from GetActivityJSDLDocuments. If I'm wrong about this, then it seems like it would be worth having an explicit explanation about how to achieve this functionality somewhere in the specification.
I think I complained about this here as well. Certainly I've complained to the JSDL people and the ESI people about this. The JDSL people answered something about keeping it simple for now. My guess is that people see it for the daunting task it is an prefer not to address it.
I'm not criticizing anyone for this. It's just my take on the problem.
JSDL describes the resources that are to be allocated to the job (err, activity) and it is not designed to handle the description of the resources allocated to the container. This matters for a whole bunch of reasons (some unrelated to this discussion) but what is crucial here is that the case you're describing only matters if you're constructing an atomic activity that is itself inherently heterogenous. Do users do that? Or are they happier with describing their task as a set of coordinated (and presumably isochronous) activities with a different JSDL-style resource requirement for each? If, as I believe, they really want the latter, we can punt the majority of the heterogenous resource mess and focus on easier things. On the other hand, there is still a need to describe heterogenous clusters; they're not going away soon. The easiest way is probably to allow the BES to publish something like multiple JSDL Resources elements, one for each kind of node in the cluster, and for the composition rule for these separate elements to be "I have *all* of these". The only complication with that approach is that it doesn't easily support the case where you want to just use resources at the lowest common denominator level, making resource matching more complex. Oh well. Donal.