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

[Karl Czajkowski]

Donal:

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"...

Consider this: within my heterogeneous activity set, I do not just
want to compose two independent constraint systems.  Rather, I want to
express some global (or even coupled!) goals about resources allocated
to more than one homogeneous array. As I tried to propose to JSDL-WG
long ago, I think there is a simple hierarchical generalization of the
jsdl:Resources model, wherein the "leaves" are homogeneous array
constraint models, and the whole tree is an aggregate constraint
model.

What I mean by the above:

   -- A "global" goal is a generalization of the current JSDL "total"
      constraint, i.e. a sum over a larger set of resources.

   -- A "coupled" goal is a restriction of the current JSDL model, as
      Marvin suggested. For example: here is my general range of
      per-resource values, but I need symmetry.  Or, this coupled
      application is malleable in time/space, but the two coupled
      codes need to be balanced according to some linear/quadratic/
      whatever relation.

We have examined this problem a bit for some other work, and we think
a modest refactoring of JSDL would make it very valuable here. Namely,
I think the "ontological" stuff regarding to sub-resources has been
nicely organized. However, there is some redundancy in the
"single/total" constraint model.

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 :-)

We can reuse the core JSDL concepts for naming and applying units to
sub-resources.  The set of scoping constructs would probably be
expanded over time.  The hierarchy of the complex resource description
would be used to group the resource constraints and provide hygienic
scoping of these more elaborate goal constraints.

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.


karl

-- 
Karl Czajkowski
karlcz at univa.com