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

[Karl Czajkowski]

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 at univa.com