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

[Marvin Theimer]

Hi;

If you structure things to explicitly support evolution and extension
then I believe you get the desired effects:
- Simple base case
- Extensions that selectively and optionally add richness while building
on the base
- An explicit sanction to make early progress on the simple,
well-understood parts of a problem without preventing future evolution
to richer, more complete solutions.

Marvin.

-----Original Message-----
From: Alexander Papaspyrou [mailto:alexander.papaspyrou at udo.edu] 
Sent: Friday, June 09, 2006 4:24 AM
To: Michel Drescher
Cc: Karl Czajkowski; Donal K. Fellows; Marvin Theimer; JSDL Working
Group; ogsa-bes-wg at ggf.org; Ed Lassettre; Ming Xu (WINDOWS)
Subject: Re: [ogsa-bes-wg] Re: [jsdl-wg] Questions and potential changes
to JSDL, as seen from HPC Profile point-of-view

Michel Drescher wrote
>> 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.
> 
> Yes! Yes! *waves the supporting flag*

I also agree. From a user's POV, I pretty much don't care on what
resource (within the constraints I specify) the job is run, just that it
is at some point.

> After reading this mail, we are probably best fitted if we provide
*two*
> resource models. Which may sound impractical, wasted resources or even
> impossible, I think the idea may be worth exploring:

I'm unsure whether one needs *two* different resource models here.

> While system administrators are interested in making the best use out
of
> their machines (simple reason: return of investment), job submitters
are
> interested in having their jobs actually executed rather than
optimised

I think this observation is correct. The whole idea is that the user
does not care about the specific resource, but only about a defined TOS
(type of service, for the non-acronym impaired), and even then, only
regarding the proper (and potentially early) execution of his job.

> A solution to this dilemma may be to provide two "languages", one
> fitting each group best: One language that job submitters use to
specify
> resources they need, which sacrifices accuracy for practicability.
This
> can be very simple, even name/value pairs.
> 
> The other language, however, aims for maximum accuracy that I envision
> to be a feature rich, (strongly?) typed representation of their
resources.
> 
> Obviously, these two languages need matching when a job is submitted.
> The natural candidate for that is (Donal, forgive me for inaccuracy
> here) "something" coming from the RSS WG.

Maybe this can be covered by one "language". Then, one would need to
specify two, let's say, versions of it:

- the provider version, which should be strict to ensure accurate
  descriptions of their service's capabilities and

- the consumer version, which is more relaxed in terms of allowing to
  leave out certain parts in order to be able to specify "loose"
  constraints for their service requirements

IMHO, this would cover what Michel suggested, but make life easier for
the involved WGs (not having to maintain two languages which are more or
less identical) and -- later -- for the implementors (not having to
provide two libraries for more or less the same functionality).
Furthermore, the match maker people wouldn't have to suffer that much...

Greetings,
Alexander

-- 
Dipl.-Inform. Alexander Papaspyrou      | 44221 Dortmund, NRW (Germany)
Robotics Research Institute             | phone  : +49(231)755-5058
Information Technology Section          | fax    : +49(231)755-3251
Dortmund University                     | web    : http://www.irf.de/