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

[Karl Czajkowski]

For clarity, I should add that I was not intending to exclude any
performance or dynamic availability indicators. I was merely trying to
emphasize that what is needed is something predictive: the types of
jobs that are acceptable, which ought to include "terms of service"
parameters such as scheduling response time in a non-trivial QoS
environment.

This is not the same thing as an administrative overview, because the
full resource set is meaningless without taking into account the
operating policies (min/max job sizes and job durations) and the
availability of the backing resources as influenced by the
(site-specific) scheduling policy and load.  And of course, this
predictive data will exist in a continuum of precision, accuracy, and
determinism.

I don't want my statement below to be misconstrued as saying the
user-level discovery is easy. On the contrary, it is MUCH more
difficult than merely enumerating resources for an administrative user
or "console" application.

Oxana makes a point later on that I also would endorse. In the absence
of good solutions to this problem, the administrative view is
necessary to allow fallback. The status quo of our field is that users
are "application administrators" who make all sorts of cunning
decisions to coax the system into behaving more optimally than it
ought to based on its own internal capabilities.  I don't think one of
these views can be addressed to the exclusion of the other.


karl


On Jun 09, Karl Czajkowski modulated:
> One thing Donal mentioned which I would like to emphasize:
> 
> The discovery ought to be "what types of job are acceptable" and not
> what resources are there.  Or rather, the latter is part of some
> administrative interface which is misleading for job-submitting users
> and middleware.
> 
> This may sound pedantic, but it will be crucial for interop. The
> discovery has to capture realistic operating policy, and not just give
> enticing catalogues of resources which can never be combined in a
> single request!

-- 
Karl Czajkowski
karlcz at univa.com