[ogsa-wg] Paper proposing "evolutionary vertical design efforts"

[Marvin Theimer]

Hi;

I have no doubt that it would be relatively easy to add transactional
semantics to most, if not all job schedulers.  In a separate email to
Ian and this mailing list I talk about the potential challenge of doing
so in a manner that is efficient enough to support
"ultra-high-throughput" HPC use cases that I'm aware of.  ASSUMING that
it is indeed difficult to support these existing use cases then I argue
it's better to support transactional job submission semantics as an
almost universally used extension than to simply exclude the use case by
requiring those semantics in the base case.

As I point out in the email, my assumption may be wrong and in fact the
main scheduler vendors/suppliers may all (or mostly all) say that
supporting transactional semantics is either something they already do
or would have no objection to adding.  In that case, we should
definitely add this requirement to the base case and happily move
forward.

Regarding your concern that I'm trying to define as small-as-possible a
base case, I'm not sure how to respond.  An important thing to keep in
mind is that I want to define an HPC profile that covers the common HPC
use cases, not just the common HPC grid use cases.  If the HPC grid
profile doesn't cover the common "in-house" use cases then a second set
of web service protocols will be needed to cover those cases
(interoperability among heterogeneous clusters within an organization is
definitely a common case).  If that happens then we risk almost certain
failure because vendors will not be willing to support two separate
protocol sets and the in-house use cases are currently far more common
than the grid use cases.  Vendors will extend the in-house protocol set
to cover grid use cases and "grid-only" protocols will very likely get
ignored.

That said, I agree with your last paragraph about the requirements for a
design, namely the need for an interoperable interface subset plus a
robust extensibility mechanism that covers the topics you listed.  But I
will argue that transactional semantics are not a REQUIREMENT for
interoperability -- merely something that in MOST cases is enormously
useful.  

Marvin.

-----Original Message-----
From: Karl Czajkowski [mailto:karlcz at univa.com] 
Sent: Tuesday, March 21, 2006 12:50 PM
To: Marvin Theimer
Cc: Carl Kesselman; humphrey at cs.virginia.edu; ogsa-wg at ggf.org
Subject: Re: [ogsa-wg] Paper proposing "evolutionary vertical design
efforts"

On Mar 21, Marvin Theimer modulated:
> Hi;
> 
>  
> 
> Whereas I agree with you that at-most-once semantics are very
> desirable, I would like to point out that not all existing job
> schedulers implement them.  I know that both LSF and CCS (the
Microsoft
> HPC job scheduler) don't.  I've been trying to find out whether PBS
and
> SGE do or don't. 
> 

Aside from the comment Ian made that it is potentially useful to have
at-most-once message semantics even if there is some potential for a
local failure in the message processing (handoff from message layer to
local scheduler), I believe LSF does support "hold" states where a job
can be submitted and released as a two-phase interaction.

Such a mechanism is sufficient to implement a complete end-to-end
at-most-once submission by implementing logging in the message engine
to associate the client message with a local job handle before
submitting.  Most schedulers also support job naming/annotation fields
which are exposed through the job query interface.  This can also be
used to implement a reliable correlation between message/request IDs
and the local implementation job.  This can also be used to synthesize
an at most once semantics in front of the scheduler, by determining if
a local job exists before trying to resubmit with the same name.  This
behavior can be hidden in the message engine and "local adapter".


> So, this brings up the following slightly more general question:
should
> the simplest base case be the simplest case that does something
useful,
> or should it be more complicated than that?  I can see good arguments
> on both sides:
> 

I find it a little disconcerting that this question is still being
asked about job systems, because there is a history of having made and
retracted this decision before.  We did it in Globus with GRAM, and I
think several of the other Grid projects did as well...

The subset interface is not sufficient for users.  A solution MUST
incorporate an interoperable subset plus a robust extensibility
mechanism to allow any of:

   1. incremental evolution of the core subset
   2. vendor-specific localization/extension
   3. community/site-specific localization/extension
   4. discovery of extended mode support
   5. graceful degradation in the absence of extended mode support

In my opinion, anything short of this will just add another
non-interoperable interface to the hodge-podge of non-interoperable
solutions that already exist.


karl

-- 
Karl Czajkowski
karlcz at univa.com