Hi; I think it's accurate to say that we're in complete agreement with each other. :-) I will be sending an email to the JSDL mailing list later today that will be similar to the original one I sent out a couple of days ago to the BES mailing list. That is, it will present some questions that I have about JSDL (from the HPC profile point-of-view) as well as a straw man proposal for a set of restrictions that the HPC profile will probably want to impose on JSDL documents it will accept as well as a set of changes/extensions that it will propose for future versions of JSDL. I will try to incorporate what I've learned from the BES-oriented discussions of the past few days. Marvin. -----Original Message----- From: Donal K. Fellows [mailto:donal.k.fellows@manchester.ac.uk] Sent: Thursday, June 08, 2006 5:39 AM To: Marvin Theimer Cc: 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 Marvin Theimer wrote:
I don't agree with the "there is no hope" argument. A set of JSDL documents can describe things like clusters from the point-of-view of available resource descriptions. A few extensions to jsdl will allow the most common forms of cross-cutting job requirements, such as "all cpus must be the same". You can probably hit 80-90% of the common cases with this incremental approach. If a well-defined way is included to allow evolution and extension then the simple design doesn't prevent future forward progress, yet still enables current progress.
I agree with the above paragraph, but I'd like to point out that the 80-90% of cases above probably should refer to distinct cases, and that it will in fact cover a much larger fraction of job throughput. There is going to be a lot of cases out there where people run the same job, time and time again (presumably with different data, though I've seen cases where that wasn't true, which was stupid). I hope that we end up with solutions that are both capable of properly solving these basic cases (I suppose you could call them the interop use-case set) and yet which do not preclude extension to taking on the bigger picture. Both are important. OK, taking on the bigger picture may need further extension profiles and new services, but that's not a big deal in my view. Donal.