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

[Alexander Papaspyrou]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
Url : http://www.ogf.org/pipermail/jsdl-wg/attachments/20060609/c5def9d6/attachment.pgp