Hi all, due to personal unexcusable stupidity, I removed parts of the session notes we took at GGF14. However, here is finally the small amount of notes we could recover, and which have been sent to me by others. If anybody has material/notes to add, please do so. Cheers, Andre. Session 1: ========== - discussion group org issues - Keith resigned as co chair, only Tom left - found new co-chairs (Andre, Shantenu) - instruct users how to present a use case - how to get application programmers to use SAGA? - feedback: should implementors focus on getting the entire implementation done, or just part of it? - feedback: agenda should be more detailed, this way other orgs will be involved - discussion of strawman API - first 3 priorities: - jobs - files - streaming - design choice: oo model - jobs: - JobDefinition may changed to even better match JSDL - Q: but would this violate the name of the group? - A: it could be still simple with setters/getters - files, logical files and namespaces pb: how to make a difference in the return type of files ops between logical files and just files connecting processes (streams) - follows the model of java-like factories Q: asynchronicity - tasks again java-like factories polling vs publish/subscribe - future issue: have task dependencies to provide API sections for simple workflows - again the issue discussed at DRMAA-1: session & job ids related to sessions -> security contexts - so far, gat-like approach: allow different types of security primitives (certificates, user/passwd, kerberos tickets) - sessions would also be defined by security context they are run in. - Comment: should add MyProxy to the other types of security. - Initial implementation experience - constraints: - ability to add new subsystems (SAGA is evolving) (write new adaptors) - adaptors - flexible adaptor scheduling - late / lazy binding - capability provider interface for one "object": there are 2 objs in the engine: - one is seen by the application - one is seen by the adaptor - the engine is in charge of scheduling the methods of that object - there are reasons not to keep everything hidden (in the sense of making the distributed app look local) Session 2: ========== - continued discussion of strawman - consistency: - all want, but most frequent is not worry... (80:20) - advisory locking helps - do good error reporting! - see NFS paper circulated by Jon McLaren on the list! - all error codes we can possibly think of, but no gtuarantee beyond that people need to check errors. - Atomicity not required everywhere, but makes much sense on constructors/destructors. Evt. move etc? - when is implementation conform? implement all? - better to have non conformacy errors earlier (compiler!) - but full implementation is preferred by apps - try to provide fallbacks of complex to simple stuff - do NOT allow NOTIMPL exception if not absolutely inavoidable - files: - eread, readv, pread: consensus: put all 3 versions as discussed into the draft, and match against use cases - fix flags! - R/W/RW flags for open... - need to be able to repeat call w/o bad effects - atomicity not necessary? - tasks: - task status: wait for monitoring - asynch needed: task model Session 3: ========== - create outline of requirement document -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+