OGSA Teleconference February 16, 2004
=====================================

* Participants

  Andrew Grimshaw (UVa)  
  Bill Horn (IBM)
  Hiro Kishimoto (Fujitsu)
  Takashi Kojo (NEC)
  Fred Maciel (Hitachi)
  Andreas Savva (Fujitsu)
  Chris Smith (Platform) 

* Summary of Actions

  Action: Andrew to rewrite vault explanation to make it clearer and
          also address relationship/contrast with existing work.
  Action: Andrew to delete implementation details such as "may have
          job service portype i/f" from JM description.
  Action: Andrew to rename EPS to scheduling service.
  Action: Delete compatibility services (it is a subfunction of
          candidate set generator)

* F2F minutes
  
  - Draft distributed to participants.
  - No feedback yet. Andreas to wait for another day or so before
    posting on gridforge.

* PE Architecture

  - Andrew made a number of revisions based on F2F discussion. For
    example, deleted the job wrapper i/f.

  - Still using OGSI terms (GSH). 
  - Confirmed that OGSA will not define detailed i/fs; other groups
    will do that.

  - For the GGF10 (PE) draft stay with paragraph style informal
    descriptions for all the proposed services/interfaces.

** Document review

   Ref:
   http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/02/msg00029.html

  - Job document: logically single document; might be separate
    (physical) documents. Can be retrieved independently.

  - The term 'subclass' may be provocative; consider changing.
    - 'Types' of interfaces is what we are really talking
      about. (classes/subclasses give the wrong flavor.)

  - Vault is new; introduced after the F2F.
    - Resources have manageability i/f; there is some redundancy in
      the text.
    - 'Vault will have methods to get a "handle" ...Called "persistent
      address"'
      - This sounds a bit like WS-Resource. The explanation is not clear.
      - A vault contains data/state. If you want to move the
        data/state to some other place you need to have a 'handle' on
        it. 
        - The scenario here is different from the one in data mgmt;
          they deal with grid exposed entities while here the
          'contained entity' is not directly exposed.
        - Checkpoint/migration is one use case.
      - One way to look at the vault is as a metadata repository
        - access it as grid service
        - What you get back is not a 'grid entity'
        - but something that depends on the back-end environment
          implementation.
  
  Action: Andrew to rewrite vault explanation to make it clearer and
          also address relationship/contrast with existing work.

  - Job Manager

    - No changes
    - Can manage multiple jobs
    - Workflow manager as example of job manager.

    Action: Andrew to delete implementation details such as "may have
            job service portype i/f" from JM description.

  - EPS
    - Name is wrong. It is a scheduler.

    Action: Andrew to rename EPS to scheduling service.
  
  - CSG
    - Might be embedded in a scheduler
    - Still useful to have it as a separate 'entity'/interface
    - Discussion on name: add 'container' to make the name more
      specific.

    - Results have no implied ordering/preference. 
      - Ordering/preference is a scheduler function. 
      - (But an implementation would be free to add more information.)

  - Information Services
    - Not part of PE. Used by PE.

  - Deployment configuration service
    - Not part of PE. Used by PE.

  - Reservation services
    - Will probably have to come back to it when WS-Agreement gets
      better defined
    - (Ability to make them & bind to them. Binding is implementation
      specific.)
    - Reference to accounting here needs more clarification.
  
  - Auditing/Billing/Logging/Accounting
    - Not part of PE. Used by PE.
    - Need to distinguish between them.
    - The definitions here are from the point of view of what PE
      needs.

    - Logging
      - Collects/maintains the information (persistency
        attribute). The base service for the rest of the functions in
        this group.

    - Accounting 
      - The scheduler uses this kind of information but does not
        maintain it. E.g., Check that the 'user' has credit to use
        this resource.

    - Auditing
      - A 'consumer' (or specific application) of logging; e.g.,
        non-repudiation function.

    - Metering
      - Attaches meaning to data retrieved from logging, e.g., measure
        resource consumption.

    - Billing (out of scope as agreed in a previous teleconf)
      - Uses the information from logging etc to bill consumer.

  - Compatibility services 

    Action: Delete compatibility services (it is a subfunction of
            candidate set generator)

  - Monitoring
    - Used by job manager
    - CMM/WSDM defining base interface. [Someone] will have to extent it
      for job monitoring.

  - Fault-detection/Recovery
    - Important but is not be just PE related. It is needed by OGSA in
      general.
    - Skip both for now and revisit at a later point and in a broader
      context.

  - License 
    - a type of resource. 
           
  - Queueing 
    - There are queues at various points, e.g., scheduler, JM etc.
    - What is different here? (Why have it as a separate entity?)
      - Some discussion on 'queued' as a job state and that a 'queue'
        is just a view into the current mapping of the scheduler or
        job manager.
    - Might be a function of the JM. 
    - Agreed to remove it.