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(a)cs.vu.nl |
| De Boelelaan 1083a | www: http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands | |
+-----------------------------------------------------------------+
