[saga-rg] Modified Charter and SAGA Session #3 notes

[Andre Merzky]

Hi all, 

here are some notes from the bitflipping meeting at GGF15
(notes taken by Craig Lee, with heavy annotations/comments
by Shantenu and me), and some general notes from stuff which
happened outside the official SAGA meetings.

Comments and questions are welcome!

Cheers, Andre.


Quoting [Shantenu Jha] (Oct 08 2005):
> 
> GGF15 was a busy meeting for SAGA and there were many productive
> developments outside the formal (three) SAGA-RG sessions. Stay tuned for
> some general notes from GGF15.

-- 
+-----------------------------------------------------------------+
| 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    |                             |
+-----------------------------------------------------------------+
-------------- next part --------------

Notes for the BitFlipping F2F meeting at GGF15 
(Minutes by Craig Lee, (major) annotations by Andre and Shantenu)

Attendendees: 
-------------

  - Andrew Grimshaw
  - Shantenu Jha
  - Thilo Kielmann
  - Hiro Kishimoto
  - Craig Lee
  - Andre Merzky
  - Steven Newhouse
  - Stephen Pickles
  - Dave Snelling
  - Dieter Kranzlmueller 

Agenda: 
-------

  - Agenda Bashing
  - Documenting the decision process
  - Finish the Requirements Doc
  - Addressing business (non-scientific) use cases and
    requirements
  - Compatibility with the SOA approach
  - Degree of alignment with OGSA
  - More specific than simple SOA alignment?
  - New charter needs to include statements indicating degree of
    (strong) alignment
  - OGGA-SAGA?

Minutes: 
--------

  - Chartering issue; 
    - Issue: scope is not well enough defined
    - Answer: defined by use cases
  - Scope hasn???t been fully spec???d yet
    - it is in the Req. doc (ahem)
  - Thilo: ???sausage before the nose???
  - Scope of group is diff from scope of document
  - split Strawman API doc in pieces?
    - was discussed: No!
  - Coordination of APIs?
    - in contact with CPR, RPC: good cooperation, more planned
  - SAGA split up into subgroups instead to turn into a single
    WG?  (could be cottage industry like OGSA)
    - premature, revisit later
  - but common look-and-feel is important
    - yes, and we will have that! 
    - efforts already being made, e.g. in contact with RPC
  - Coordinate with other groups/APIs, e.g., JSDL and DRMAA 
    - in progress!
  - modify charter to reflect sync with OGSA etc.  (don???t want
    gap between OGSA and SAGA, i.e. between middleware model and
    API)
    - see mail about revised WG charter
  - implementability/compatibility of SAGA on top of
    GT2/OGSA/..., w/o implementors dying horrible death
    - need feedback and input (sanity check) from OGSA on final
      spec (paradigms compatible?  Assumptions to model?
      Feedback from SAGA to OGSA and vice versa!)
    - SAGA reference implementations need checks against OGSA
      compliant implementations as those become available
       - Sanity check if OGSA and SAGA fit?  Need
         implementations!
       - File I/O ??? byte io spec, name space spec, ???
       - Mixed team for sanity check
       - Workshop?
  - charter statements:
    - Will coord w/ OGSA and other groups as necessary
    - OGSA-SAGA (OGSAGA) group? 
      - No but want to be broad
      - OGSA-SAGA profile?  a potential coordination mechanism,
        needs discussion (e.g. a SAGA-GT2 profile would mask out
        the call job.migrate (), as GT2 does not support it)
        - need to clarify what is supported by diff middleware
          bindings (the current statement in the API document is:
          "MUST implement as much as possible")
    - Housekeeping: SAGA-WG on GridForge ??? just start using it

Conclusion:
-----------

  - Finishing the Requirements doc to document the decision
    process should be done but SHOULD not be a pre-condition for
    becoming a working group
  - The general consensus was that SAGA is ready to become a
    working group (hurray!)
  - mentioned issues have been discussed in the RG, and should be
    publicly reflected by the new WG charter etc.
  - We just need to manage the process to address issues of
    scope, SOA compatibility, degree of alignment with OGSA etc.
  - SAGA-RG will produce a WG charter proposal addressing the
    issues above
  - Lets go Party!
    ==============

-------------- next part --------------

General Notes from GGF15 (Boston):
==================================

  - Charter discussion:
    - see NOTES.bitflipping.txt
    - see new WG charter proposal (session 3 notes)

  - GridCPR:
    - consider adoption of SAGA look&feel
    - are interested in _using_ SAGA API calls internally (?) to
      contact middleware (e.g. to move a file)
    - are intersted in async notification for checkpoint
      requests etc.
    - lessons learnt:
      - SAGA API document should make clear which parts are
        'look&feel', which parts are middleware interactions
      - async notification is of interest
      - after stable SAGA-V.1, GridCPR might be a candidate for
        future extended SAGA-V.2 scope
        
  - GridRPC:
    - SAGA has many RPC use cases
    - there is enough overlap to consider having RPC as a
      subsystem in SAGA at some point in the future (once again,
      after stable SAGA-V.1, in a future extended SAGA-V.2 scope)
    - there were interesting dicussions about the async call
      models used in SAGA and GridRPC - see additional notes
      about the task model discussion
    - there is an agreement to discuss a SAGA RPC subsystem on
      the mailing lists, and in future F2F meetings

  - SAGA visibility:
    - many sessions (API and middleware) mention and refer to
      SAGA
    - we got a slot in the closing plenary to present our
      progress
    - there we got feedback from Malcolm: do we consider a SAGA
      API for OGSA-DAI?  Is that in the scope of the group?
      Answer: not unless use cases and active involvement

      We had further discussions with Malcolm and Dave Snelling.
      The general message from them was that SAGA like APIs might
      prove useful at multiple levels: application oriented (as
      our current strawman API), and also closer to middleware
      models (e.g. a SAGA like API explicitly representing the
      OGSA model), and in between (e.g. for OGSA-DAI).

      Our point of view is that although this present interesting
      opportunities, it significantly increases the complexity
      and scope of SAGA and will not be possible without critical
      input from the various interested groups at the different
      levels. Thus extending SAGA in this direction is felt to be
      out of our scope and ability at the present moment.