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

[Karl Czajkowski]

Marvin:

I think one decision to make is whether BES services are homogeneous
or not.  I think Donal is advocating homogeneity. However, I do not
think this is the main source of complexity.  In either case, I agree
with you that JSDL ought to be usable as a core syntax for describing
the "resources available from a BES instance" as well as the
"resources required for an activity".  As you describe it, this is
sort of a "class ad" in the Condor sense of the word. The problem
comes from trying to advertise a resource that can handle multiple
jobs simultaneously.

The tricky part is that this is not just "nodes free", but must be
intersected with policies such as maximum job size.  Should there be a
vocabulary for listing the total free resources and the job sizing
policies directly?  Or should the advertisement list a set of jobs
that can be supported simultaneously, e.g. I publish 512 nodes as
quanity 4 128-node job availability slots?  The latter is easier to
match, but probably doesn't work in the simple case because of
combinatoric problem of grouping jobs which are not maximal.  How does
a user know that they can have quantity 8 64-node jobs or not?

Also, I am ignoring the very real problem of capturing per-user
policies. I do not think it is as simple as returning a customized
response for the authenticating client.  How is middleware supposed to
layer on top of BES here? How does a meta-scheduler know whether
quantity 8 64-node jobs can be accepted for one user?  For 8 distinct
users?  Does a (shared) meta-scheduler now need to make separate
queries for every client?  How does it understand the interference of
multiple user jobs?  I think there is really a need for a composite
availability view so such metaschedulers can reasonably think about a
tentative future, in which they try to subdivide and claim parts of
the BES resource for multiple jobs. Can this be handled with a
declarative advertisement, or does it require some transactional
dialogue?  The transactional approach seems too tightly coupled to me,
i.e. I should be able to compute a sensible candidate plan before I
start negotiating.

If we say all of this is too "researchy" for standardization, then I
am not sure what the standard will really support. Perhaps the best
approach is the first one I mentioned, where relatively raw data is
exposed on several extensible axes (subject to authorization checks):
overall resource pool descriptions, job sizing policies, user rights
information, etc.  The simple users may only receive a simple subset
of this information which requires minimal transformation to tell them
what they can submit. The middleware clients receive more elaborate
data (if trusted) and can do more elaborate transformation of the data
to help their planning.

The only alternative I can imagine, right now, would be a very
elaborate resource description language utilizing the JSDL "range
value" concept to expose some core policy limits, as well as a number
of extensions to express overall constraints which define the outer
bounds of the combinatoric solution space.  This DOES seem pretty
"researchy" to me... but maybe someone else sees a more appealing
middle ground?


karl

-- 
Karl Czajkowski
karlcz at univa.com