OGSA Program Execution teleconf - Nov 3, 2003
=============================================

* Participants

  Andrew Grimshaw
  John Tullefsrud
  Ravi Subramanian
  Jeffrin Von-Reich
  Chris Smith
  Takashi Kojo
  Hrabri Rajic
  Hiro Kishimoto

  Note-takers:  Andrew Grimshaw and Hiro Kishimoto

* Actions

   Action: Hiro to upload Platform JSDL terms proposal to the PE
           folder. >Done.
   Action: Andrew will send out refactoring document.
   Action: ALL read Platform's(OGSA portions) and DRMAA docs by next Monday.
   Action: Andrew to send out picture for pragmatic approach for next
           week.
   Action: John to send pointer to DRMAA document. >Done.

* Agenda bashing

  - 2 documents expected from last time:
    - Glossary(posted to the tracker), 
    - PE private session GGF9 minutes(not posted yet)

* Minutes approval postponed

* Refactoring

  - Refactoring is fine but...  also have to produce deliverables
    fast (in a reasonable timeframe)

  - More flexible/general architecture is good

  One approach is 
  1) running legacy jobs on OGSA in the short term
  2) Ravi's document (generalization) in the long term

  Platform: Legacy systems driving the architecture.

  Andrew:
        Lots of other groups are thinking about these things. Lots of
        examples, GRAM, other queueing system, simple wrap up of
        existing system.

        - Legion (avaki?) to release source; could reference it in a
          scheduling architecture.

  John:
        There are a couple of different approaches. E.g., short term
        pragmatic and long term generalization. OGSA based grid.

  Andrew: Ravi has proposed a generalized approach.
          People also need APIs. 
          Doing generalized approach may take long time (long term goal).

         We did legion in 2,3 months but standards bodies take longer.
         Rapid development is possible but I hesitate to take on the
         job of putting both in the OGSA doc by GGF10.

  Agreed on a two phase approach
        Short term: wrapping, existing system (platform's proposal)
        Long term: refactoring (ravi's proposal)

        - Andrew, Ravi, Jeffrin, are interested in doing
          refactoring (long term).
        - Platform and DRMAA focus on short term.

   Question for the whole group: We could write API based on the
   existing systems. (It is easy to do a service interface using
   existing i/f as examples.)

   Ming's document is in the current OGSA doc. (The document was
   refactored so the service definitions are in later
   sections. Andreas pointed Andrew to the correct location on gridforge.)

   Platform has defined and implemented CFS. It is WS-Agreement based.

   Platform has submitted proposal to JSDL-WG for computational job term
   definitions. It will take some time before something comes out.

   Does OGSA-WG define interfaces: Yes and no. We can suggest but the
   group that takes on the job has finally say.

   Terms discussion (models)
         One term is called executable that includes a pathname.  What
         does pathname mean?  What is implied? Has everything been set
         up already, e.g., licenses.  Also filesystem assumptions.

  Does DRMAA include architecture issues?  DRMAA has a simple model.
  Late binding but tightly bound to a back end DRM.

  Applications can get benefit from simple model easily. But more
  sophisticated applications can get benefit more from i.e. service
  oriented architecture

  DRMAA tried to achieve write once, run one or more drm
  underneath. (But API definition is currently tied to one DRM?)

  Do we merge PE and resouce management?
  jnick comment: rename PE to  something like provisioning.

  We also need some kind of resource model. Is that CMM?  CMM deals
  with management i/f not resource models. (Don't confuse it with the
  initial CRM proposal.)

  CDDLM addresses (will address) deployment and configuration. It is
  based on HP's smartfrog. (There is an associated resource model.)

  Kojo: CDDLM does configuration description, deployment lifecycle
        management.