Hi all, Petr Tr"oger took some notes in the first session, and Ana recovered them (thanks to both!). Here they are: SAGA-RG Session 1 ----------------- - All chairs but Tom left, search for new co-chairs - Flipping the bit - Strawman API - needs WG in order to make it a GFD-P-R one or two GGF's away from standardization document - new group maybe no good idea - double work - Dave Snelling will make a review of the Strawman document - Tom: Best idea would be to spawn a working group for each part of the API, but problem with man power - For new WG, BOF is technically not needed - good usage examples are already there, talk to application developers - especially from EU projects (old and new GAT users) - Idea Thilo: hands-on session for SAGA, using the first implementation prototype - should happen co-located with another conference / meeting - intended audience are also FP6 projects - particle physics conference as opportunity - Use case document - Available in Wiki and GridForge - Functional SAGA blocks kept independent, makes implementation easier - SAGA conformance check list necessary - Strawman API - still needs discussion by full group - look at the three highest priorities from use cases (jobs, files, streaming) - considered async. calls - abstract API design using an OO model (first bindings will be C++, Java, Python) - thinking about using JSDL terms for JobDefinition attributes - namespaces as paradigm for file access seem to be relevant - file read / write operation: pending discussion about scalability in remote case - work of OGSA ByteI/O should be considered - danger of duplicated work - task dependencies will be supported in the future, based on Task model - Security and sessions are missed - Session concept for encapsulation - Security like GAT: Context object with security information - Andre: Implementation experience - CoreGRID / C++ - not all artifacts represent remote handles - late / lazy binding; allow to add new subsystems - learn from GAT - flexible adaptor scheduling (avoid non-deterministic GAT approach) - operations in SAGA objects can be provided by different adaptors - Consistency model discussion needed - Don't pretend to be local when it is remote (POSIX semantics are bad for such a use case) Quoting [Andre Merzky] (Jul 28 2005):
Date: Thu, 28 Jul 2005 20:19:02 +0200 From: Andre Merzky <andre@merzky.net> To: Simple API for Grid Applications WG <saga-rg@ggf.org> Subject: GGF meeting notes
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 | | +-----------------------------------------------------------------+