June 2006 - saga-rg - lists.ogf.org

AlreadyExists
by sbrandt＠cct.lsu.edu 22 Jun '06

22 Jun '06

I'm new to the Saga list and have started to look over the java code and various docs. I'm wondering if the exception AlreadyExists might be eliminated from the SAGA spec, in favor of different behavior -- namely to do nothing in the case where AlreadyExists would normally be thrown. This should be reasonable for mkdir(), adding a context, etc. I believe this would be simpler and nicer for users. Cheers, Steve

2 3

ISSUE 132
by Andre Merzky 22 Jun '06

22 Jun '06

132) when do we refer to target host name, and when to resource manager contact, on job submit/description? Se mail thread with Graeme/Chris "JobService.submitJob() query" - OPEN, URGENT See also the comment from Graeme to the list today below: > Andre, > > The client must be able to specify the resource manager to which jobs > are submitted, as a service URL or machine name. This should be a > argument for either the JobService constructor, or the > JobService.createJob() & JobService.runJob() methods. > > I guess that conceptually I prefer specifying the resource manager > during the construction of the JobService object. However in an earlier > mail Chris Smith indicated that the 'host' argument of the runJob() > method was originally intended to indicate the machine upon which the > job should be run (mapping to an element of the SAGA_HostList > attribute). This is confusing and the 'host' argument should be removed, > or redefined to indicate the resource manager. > > Graeme I propose to go with Grames proposal unless there are opinions to do differently. I like the version to redefine the host arg better than to remove it altogether. Other opinions? Thanks, Andre. -- "So much time, so little to do..." -- Garfield

2 4

Re: [saga-rg] ISSUE 90
by G.E.POUND＠soton.ac.uk 22 Jun '06

22 Jun '06

Andre, Please find attached comments on the Exceptions thrown by the methods of JobService and Job in the Java bindings (including changes that I must implement). Most are quite straight-forward, apart from JobService.createJob(). Graeme Quoting Andre Merzky <andre(a)merzky.net>: > That would be useful! Malcolm should also have some idea on > what error handling is exposed by his implementation, that > might be useful as well. > > Our implementation has no job so far *sigh*. > > Thanks, Andre. > > > Quoting [G.E.POUND(a)soton.ac.uk] (Apr 20 2006): > > > > I can feedback the exceptions that I found essential from the Job > package in > > the Java bindings. > > > > Graeme > > > > > > > > Quoting Andre Merzky <andre(a)merzky.net>: > > > > > 90) exceptions missing in job! > > > - OPEN, URGENT > > > > > > Well, that says it all. > > > > > > Volonteers? > > > > > > Cheers, Andre. > > > > > > > > > -- > > > "So much time, so little to do..." -- Garfield > > > > > > > > > > > > > > > > > > > > > > > > -- > "So much time, so little to do..." -- Garfield > > >

2 1

Requirement Document - Group feedback needed...
by Andre Merzky 22 Jun '06

22 Jun '06

Hi Group, the SAGA Requirement document is, finally, getting close to publication. Attached is the current version, which we intent to submit to GGF Office on Friday night. This is the 'last call' for the group to provide feedback on the draft, or (preferrably ;-) to give us a 'go ahead'. Two notable points might change before submission: the author list might get extended (please speak up if you feel left out, or have suggestions!); and the Java-CoG sections needs revision - we are waiting for input from Gregor on that. Please provide feedback as early as possible, to allow us to keep our Friday submission deadline. Comments after (local) businness hours are very likely to be ignored (for this version). Best regards, Shantenu and Andre. -- "So much time, so little to do..." -- Garfield

3 3

some principle comments on SAGA
by alexander.beck-ratzka 22 Jun '06

22 Jun '06

Hello SAGA developers, first of all: I am not taking part in developing SAGA, but I try to distribute GAT within the german D-Grid community project, and therefore I know about the SAGA efforts, and - as I feel - I also see some problems in the realisation... Okay, let's start with the problems of GAT. As GAT has started, it missed a lot of adaptors to the mostly ditributed grid middleware products. This is - at least in Germany - a fundamental reason for the very low acceptance of GAT in the Grid Community. As far as I know SAGA seems to inherit this deficiency of GAT. So Andre statet recently in a Email to me: "... we can definitively support only some adaptors, and we need the help of those projects, which have to develop AND SUPPORT adaptors to their middleware..." Please dont understand me wrong: I know about the small personel resources in the SAGA project, and that therefore only the development of a "SAGA Engine" and some local adaptors is possible. However, the missing of adaptors to Globus, Unicore or Condor etc.., is an urgent problem. The acceptance of software increases with its possibilities ot use it. If SAGA delivers now only an engine without a connection to any grid middleware, I would also not use SAGA to access e.g. Globus grdi functionality. Why should I develop an adaptor to my grid middleware (and even support it later on) for enabling the usage of SAGA; in such a case it's easier to develop directly against the middleware API. If I develop an adaptor, I'll have to possible regions where problems can arise: SAGA and the access to the middleware API. Developing diretyl against the middleware will only bring problems with the middleware API. I believe that such preconditions will not lead to a wide acceptance of SAGA! How to get rid of this problem? I like to suggest to deliver a SAGA toolkit. Beside the engine there also should be delivered a set of adaptors to the mostly distributed Grid middleware, as Globus, Unicore, Condor, etc... But how can this bed realised with the restricted resources? I have had the idea that the CCT should increase its support of the SAGA development, in Germany, there is no money available (at least right now). I don't know, if this is possible, but I'm quite shure that it must be a SAGA toolkit instead of a SAGA engine with local adaptors, if SAGA should be successful. I hope, you understand my words as a helpful comment. I want SAGA to be successful, and therefore we have to think about a SAGA toolkit. Cheers Alexander

2 1

Minutes from SAGA-CORE-WG at GGF17, 1st session
by Thilo Kielmann 20 Jun '06

20 Jun '06

Meeting of SAGA-CORE-WG at GGF17 1st meeting, may 11, 3:45 - 5:15 Session chaired by Andre Merzky Notes taken by Shantenu Jha, Thilo Kielmann Agenda: - agenda bashing - work on issue list for the SAGA1.0 spec Andre opens the session, circulates the sign-up sheet, referring to GGF's IPR policy. agenda bashing: --------------- the agenda is accepted "as is" by the participants open issues from "the list": ---------------------------- job states ---------- the state diagram is revisited Q: remove (or defer) job.checkpoint ? (->gridcpr) what about job.migrate ? the discussion is leaning towards a 2 layer state model: - a generic level - detailed BES model the differences revolve around "hold" states of jobs. Queueing systems do provide them, but applications seem to have little (no?) use of it. (see: SAGA use cases) How much should a SIMPLE API (-> "S"AGA) expose? It is clear that SAGA states should be compatible with BES, however, possibly only have a proper subset in the generic level, and the full detail in the detailed level. action item : list the options, come to rough consensus have layered model Andre to place discussion both (bes and saga) mailing lists further issues from the issue list that were discussed: 12, yes change 29, see 2nd session (Stephan Hirmer's talk) 30 ACLs Q: are all ACL systems equal? e.g., NFS ACL vs WinFS vs Solaris AFS and will that cause problems? Andre agrees: SAGA has an omission - no provision for distinguished names Line 81: strawman_namespaces ACL_Admin ==> replace with ACL_Owner?? no! "admin" describes better the role of maintaining; these could be multiple users, not just the single owner Use Base Case approach for security? e.g. look at all the diff OS there is commonality and then specific issues Andre: to post on the mailing list.. 36, language examples missing (not discussed) 47, jsdl compliance and 88, clean up files JSDL has the notion of which files to get rid of after execution, but support for this feature will be limited. JSDL: keep, remove, don't care (default) Andre: Add an attribute "clean_up" 55, references, not discussed editing "only" comments skipped 102, what classes need error handler ErrorHandle -- defined for languages like C - that do not have an error interface. interface error_handle provides the ability to rethrow errors ! provides guidelines for how procedural languages should handle errors. check "has error type" ??? -> ask Tom -> add errorhandler interface to task get_Error has_error 108 constness of operations do it in prosa, in/out/inout remain as in SIDL 111 file constructors do open implicitly agreed. 132, bind resource manager to jobservice (in constructor) runjob needs to be discussed on the mailing list Andre promises to buy beer for people willing to help writing/editing the spec doc. (From the note taker: it was not clear whether the beer should be paid before or after editiing the document.) At 5:15, the session is closed.

2 1

FYI: Lessons Learned from CORBA
by Andre Merzky 20 Jun '06

20 Jun '06

Hi folx, I stumbled over the following article twice in the last weeks, read it twice actually, and found it really worth the time. http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=396 If you don't have the patience to read 4 pages online, I recommend the sections 'Procedural Issues' on page 3, and 'Lessons learned' (page 4). I think there are lessons for GGF as well, but definitely for SAGA. Cheers, Andre. -- "So much time, so little to do..." -- Garfield

1 0

test, please ignore
by Andre Merzky 13 Jun '06

13 Jun '06

nt -- "So much time, so little to do..." -- Garfield

1 0

sessions at GGF17...
by Andre Merzky 13 Jun '06

13 Jun '06

Hi Folx, the sessions scheduled for GGF17 are: Wednesday, May 10 1:45 pm - 3:15 pm, room G-408 Wednesday, May 10 3:45 pm - 5:15 pm, room G-408 Thursday, May 11 3:45 pm - 5:15 pm, room G-408 Friday, May 12 11:00 am - 12:30 pm, room G-408 The agendas we originally proposed are somewhat out of sync with the status of the group work, so we would like to propose the following agendas. Feedback is appreciated. We intent to publish the agenda on the GGF web pages on Sunday morning. It is recommended to read both the SAGA Requirement Document and the SAGA API specification prior to the sessions. That is not to scare people away if they don't read the docs, but efficiency of the meetings will certainly improve with familarity with the work done in the group so far. The agendas below also imply that reading of other GGF specs and drafts (JSDL, BES, DRMAA) would be very beneficial. Cheers, Andre. Session 1 (RG): --------------- The new SAGA-RG incarnation will discuss administrativa, and plan collaboration with other GGF groups (RPC, CPR, SAGA-CORE, ...). A short overview presentation of the current SAGA API is included for bypassers. Agenda: - administrativa - SAGA overview for the crowd (3 slides), announce other sessions etc - evaluate the SAGA REQ document, and derive RG scope out of that - sync with RPC and CPR, finalize on design teams Session 2 (RG): --------------- The SAGA-RG will flesh out the work of the RPC and CPR design teams, and work on synchronization with other GGF groups in general. Agenda: - plan for real req. document for these design teams - work on SAGA-RPC draft - work on SAGA-CPR draft (if available) - synchronize with (and plan for future) new specs in GGF (GFS, BES, JSDL, ...) (we should READ them before GGF) - considerations about a SAGA look-&-feel spec (based on the look-&-feel parts of the core spec) Session 3 (WG): --------------- - discuss parts of API which should be moved into the RG look-&-feel document (object, task, ...) - update on issue list, try to close remaining items - define timeline/responsibilities for finalization (editing, proof reading, consistency checks) - define timeline/editors for cook-book Session 4 (WG): --------------- - continue on open issues if needed - define editors and format for language bindings - update on implementations - discuss bulk optimizations -- "So much time, so little to do..." -- Garfield

7 14

The URL problem
by Mark Mc Keown 13 Jun '06

13 Jun '06

I have started looking at the SAGA strawman document and wanted to comment on the section "The URL problem". URL -> URI ---------- In many circumstances URI has replaced URL, see for example Web Arch (http://www.w3.org/TR/webarch/) URIs allow you to identify things for which there may not yet exist a representation - for example an output file for job that has not started or http://host.net/tmp/file in the SAGA document. Comparing URIs -------------- Rules for comparing URIs are scheme dependent, so you cannot compare a ftp URI to http URI, see http://www.textuality.com/tag/uri-comp-4 and http://www.faqs.org/rfcs/rfc2396.html. The SAGA document effectively says this but I am not sure there is any need to go beyond saying you cannot compare URIs from different schemes. Two URIs with different schemes can identify the same resource, ie they are aliases, but you cannot tell this from comparing the URIs. However redirection may be used to relate the URIs. For example a HTTP redirect: a user may get a 3XX response when attempting to retrieve a representation of resource using HTTP which points him to a FTP server. So there is a question of how SAGA would handle a redirection - redirection of POST or PUT in HTTP requires user input. any scheme ---------- The W3C recommends not inventing schemes, section 2.4 of Web Arch. cheers Mark

2 1