Folks, I think we are having conflicting goals here. (Technical goals, not personal ones ;-) On one hand, we have the "S for simplicity" in SAGA, and we must keep it. On the other hand, we have the necessity to support JSDL, future JSDL extensions, or any other types of job decscriptions that people want to use. (And still might to be invented.) Assume, JSDL++ (whatever it will look like in near future) will become a widely adopted standard. (Or anything else, doesn't matter in the following.) Then, SAGA implementations will have to use JSDL++, and to form JSDL++ from SAGA job descriptions. Simultaneously, users are likely to use JSDL++ themselves, and may wnat to use JSDL++ to express their resource needs. At this point in time, SAGA will sit in the middle, and it may be very clumsy to first translate from JSDL++ to a SAGA job description, and then back to JSDL++ somewhere "down under" in the implementation. For the very purpose of SAGA as a universal and simple grid API, it has to: - be independent of job description standards (mostly simpler than them) - support job description standards My suggestion: SAGA should have one class of job descriptions, and the possibility to create subclasses for more specific job descriptions (like JSDL). Such subclasses could be defined as separate extension documents (just like gridcpr). (Or was it "resource descriptions"???) With this approach, users could still write programs that are independent of the underlying job submission machinery, having a simplified view on jobs and resource attributes etc. etc. At the same time, subclassed job/resource descriptions could be "passed through" transparently from the API to the implementeation, without being converted back and forth, a process that is very likely to loose some important details. Is this a route to go? Thilo On Tue, Feb 13, 2007 at 06:28:58PM +0100, 'Andre Merzky' wrote:
From: 'Andre Merzky' <andre@merzky.net> To: SAGA RG <saga-rg@ogf.org> Subject: [SAGA-RG] Fwd (andre@merzky.net): Re: JSDL - SAGA
Hi group(s),
a couple of us had a recent discussion (f2f and email) about JSDL and SAGA. The question is: should we support JSDL fully on API level? E.g., should we allow the application programmer to specify/use JSDL documents for job creation?
The reasons for doing that are compelling: JSDL is one of the most acknowledged standards in OGF, and the number of backends supporting JSDL is rapidly increasing it seems. Supporting JSDL directly would allow to interface with other tools using JSDL, and would allow to reuse JSDL documents where these are already available.
Well, I have however some problems with that approach, which are outlined in the cited email below.
Do you guys have any other thoughts, and what solution would you prefer?
Cheers, Andre.
----- Forwarded message from 'Andre Merzky' <andre@merzky.net> -----
From: 'Andre Merzky' <andre@merzky.net> To: Shantenu Jha <sjha@cct.lsu.edu> Cc: Hartmut Kaiser <hkaiser@cct.lsu.edu>, 'Thilo Kielmann' <kielmann@cs.vu.nl>, 'Andre Merzky' <andre@merzky.net> Subject: Re: JSDL - SAGA
Hartmut and I discussed that somewhat last week. So he knows I am not wholehartedly for that option. SAGA is supposed to abstract the low level details, not to expose them.
JSDL is going to define a number of extensions now. Some of these extensions are very useful for us, others not. Mostly, they will be more complex than JSDL itself.
Are we going to support the extensions? Which? All/some? How to select? What error do we report on unsupported extensions? Do we mandate that extensions are supported by the backends? Which?
Even w/o extensions: is the job description updated after an JSDL attrib is set? What about those attribs which are not JSDL keys? Assume an implementation which implements the existing SAGA job description keys: MUST it support complete JSDL now? What error whould it report?
These are probably all solvable problems, and I do agree that there are advantages, i.e. the re-use of existing JSDL documents. Anyway, IMHO we should be careful, consider if we really have enough use cases etc. Also, a free function jsdl_to_job_description may do the trick, w/o complicating the job package itself.
Cheers, Andre.
Another point I'd like to raise is: if HPC profile bekomes a widely accepted OGF standard, do we support it directly, too? Or OGSA-Workflow? Where to stop, and where is the 'S' in that approach?
Andre.
Quoting [Shantenu Jha]
What little I know, I think so to.
Quoting [Hartmut Kaiser]
Agree 100% The easiest way is probably just to add a attribute in the job description taking the whole JSDL.
Quoting [Thilo Kielmann]
Yes!
Quoting [Shantenu Jha]
Shouldn't we ensure that SAGA consumes JSDL w/o any problem/changes?
-- "So much time, so little to do..." -- Garfield -- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
-- Thilo Kielmann http://www.cs.vu.nl/~kielmann/