[saga-rg] Re: GGF meeting notes

[Andre Merzky]

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 at merzky.net>
> To: Simple API for Grid Applications WG <saga-rg at 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 at cs.vu.nl       |
| De Boelelaan 1083a                | www:  http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands    |                             |
+-----------------------------------------------------------------+