[ogsa-bes-wg] Questions and potential changes to BES, as seen from HPC Profile point-of-view

[Marvin Theimer]

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 at manchester.ac.uk] 
Sent: Thursday, June 08, 2006 5:39 AM
To: Marvin Theimer
Cc: ogsa-bes-wg at 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.