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.