On Jun 06, Donal K. Fellows modulated:
Karl Czajkowski wrote:
The main concern, I think, is that JSDL is "so close" to having the right terminology for both levels. It would be a shame to lose focus and have to repeat the effort again later. I do not think the heterogeneous solution is a simple "bag of JSDL documents"...
I think this is getting rapidly off-topic for BES. ;-)
Sorry, I didn't notice this thread was only on the BES list... for some strange reason, I thought it was copied to JSDL. (Is there any point in my forwarding the previous message to JSDL-WG?) I am not following some of your points, because I thought the topic was the resource constraint model used in JSDL and thus BES jobs as they stand today. It was not about publishing resource models to support discovery, though I do appreciate that there ought to be a complementary discovery system for _any_ rich resource management capability. I thought the submission constraint model was the question raised by Marvin too, with respect to HPC scenarios. BES cannot be basic and serve any purpose behind exotic selection and planning services, if the meaning of a job cannot be formulated precisely. Surely, the idea isn't to do fancy planning and then strip away all the important constraints, throw the job over the fence to BES, and hope for the best! So, either BES needs to capture the application-level constraints, or it needs to capture some intermediate "placement directives" generated by the scheduler intervening between user and BES.
... I don't think it is a practical proposal for interoperability. Either there's a common profile with no significant extensions to it or there's a standard semantics for reconciling terms from one part of the term-space with terms from another part. The first is pretty much equivalent to ignoring your proposal (except with more matching complexity! Yay!) and the second is extremely difficult. The other alternative (that I do not want) is for there to be systems out there that claim to support the same standards, but which profile them in such different ways that interoperation is nigh-on impossible. That's where we are right now, in effect.
I'm not sure I buy the specific three categories you've described. But, is it fair to summarize as follows: you doubt there is a general model that covers the more complex constraints out there in a way that is interoperable, because either no intermediate profiles exist, or implementations will not actually support the profiles? You believe that the only feasible point for interoperability is the current resource array construct in JSDL 1.0, which supports symmetry only with exact (single-valued) resource constraints and which supports non-deterministic heterogeneity with variable (range-valued) resource constraints? Personally, I think that if there is no hope for some interoperable "extension profiles", there is not much point in BES nor in the HPC standard Marvin is championing. There are already a number of good-enough systems which capture the easy case. If we want to be this conservative in covering only the low-hanging fruit, why not just formally document an existing de-facto standard interface, perhaps filing off the rough edges where too many implementation techniques are assumed? karl -- Karl Czajkowski karlcz@univa.com