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

[Donal K. Fellows]

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. ;-)

We want to have at most a simple model for basic execution. Or even no
resource model at all. There's no particular reason for BES to publish
any information about the resources that it is in front of; that is the
responsibility of the information service infrastructure and (on the
consumption side) resource selection services. Requiring the use of a
published information model (let alone one as complex as you're
proposing) precludes many possible implementations for what are
effectively non-functional reasons.

And most (probably way over 99%) of the activity on the grid is, and
will continue to be, simple jobs/activities. Too much effort, not enough
return.

> I think a more general composition of the core concept, e.g. "memory",
> and a scoping construct, e.g. "per resource," "sum over resource
> array," or "sum over heterogeneous aggregate" would be better. I
> haven't thought about the coupled cases much, so I do not embarrass
> myself with short English phrases for them :-)

What about clusters that provide a shared memory (OpenMP) model; do we
have to introduce another modifier to deal with that? What will the term
mean when applied to the other resources? And the next extra thing that
wasn't originally thought of? What happens if a resource may be a member
of multiple heterogenous aggregates simultaneously, with some defined by
the user's VO?

Can we get away without opening this high-pressure can of worms? :-)

> The idea I am advocating is to have one general constraint model that
> is hopefully neutral, such that it can be mapped to the local
> constraint model of various schedulers or meta-schedulers.  No single
> service would necessarily implement the fully general model, but would
> rather support profiled subsets of this model. The benefit is that the
> different profiles are all related by a common model, and it is
> feasible to consider more general solvers/profiles being introduced
> over time.

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 was writing a much longer response to your message, but decided that
a total point-by-point rebuttal was foolish. And this is the wrong place
to make a fool of myself.]

Donal.