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

[Donal K. Fellows]

Karl Czajkowski wrote:
> I'd go a step further, and say that these relationships are
> application specific and not intrinsic to the OS or architecture. The
> underlying matching system should include some logical combining
> mechanism, and "user friendly" client-side tools should allow
> imposition of certain ordering idioms if this is desired.  I don't
> think ANY standards body will capture all of the combinations which
> matter to applications, unless they produce a logical combination
> structure and canonically name nearly every combination. ;-)

If I remember right, this is why the only matching semantics that are
actually defined for operating system or CPU type by the JSDL spec are
"exact match" despite that being not very useful in most cases. Another
case that has the same problem is application version; some apps define
a sane scheme, but others are just mad (for example, the Linux version
scheme where the low bit of the second digit indicates stability status
and not actual versioning, and Java product versioning is driven by
marketing and not technical utility). Exact matching is the only
universal matching plan, but it does not serve users well; if a point
release has been done to fix some obscure bug, why should that
invalidate a user's job submissions? They probably weren't bitten by
that bug in the first place.

The best approach for users is for them to only give CPU types, OS
types/versions and application versions when they *really* need it, and
for them to leave those resource facets unspecified otherwise. Indeed,
that works well in highly managed environments (such as those targetted
by UNICORE) where applications are things that are installed by admins
and users just use them. That's obviously not what everyone wants, but
perhaps it is all that can be done interoperably. :-(

Donal.