Meeting - Tuesday, 8 Dec 2009, 16:00 (CET)

Participants:
Morris, Balazs, Etienne, Johannes, Aleksander

Agenda:
  Discussion of the work of Etienne on the "OGF PGI - AGU Execution Service Strawman Rendering"

Morris:
  Go through meeting notes from last meeting
  Would be good to have gLite participation

Balazs:
  We need at least one more person from gLite
  Real work can only be done with a screensharing tool
  Just discuss the ideas behind Etienne's work

Balazs (chairing the strawman rendering document discussion):
  Doc is the latest version of the doc (version 37) by Aleksander on the PGI GridForge page
  Page 4
  Synchronize, merge Etiennes's changes with actual model

  Inside createActivity (second sentence)

Etienne:
  The initial state of a job is the submitted state

Balazs:
  Substates ?

Etienne:
  Substates of 'Submitted' state are :  Incoming, Waiting, Outgoing
  - Incoming = Job inside input queue, has not been processed yet
  - Waiting  = JSDL is being processed
  - Outgoing = JobId or EPR has been given to the job, ready for next
state
  Any change must be performed in a consistent way

Balazs:
  Combining substates in a certain way -> clarify more
  Not combine submitted outgoing with response

Etienne:
  It is useful that each state really represent something
  If you do not give JobId at the end of 'Submitted' state, you have to
completely include the 'Submitted' state inside the 'Pre-processing' state.

Balazs:
  Only the first level states, 2nd third are optional?

Etienne:
  Important: at the end of submitted state - JobId associated

Balazs:
  Why at the end ?

Etienne:
  At latest at the end !
  Could be returned earlier also
  It is useful for the execution service for checking if it is possible
(JSDL checking)

Balazs:
  Not validate JSDL here
  When does execution service return response ?

Morris:
  Page 4, comments
  - In terms of UNICORE it is alway possible directly, you don't do brokering
  - Not exactly sure how this relates to the state model
  - Out of the scope of the session ?

Balazs:
  Now, we are not discussing staging of data
  We are discussing in which state job should be
  I do not see this written down now

Morris:
  It is in the job description document validation

Balazs:
  Missing the state model
  How do you read the job description validation?

Morris:
  Matchmaking
  If there is a must - there is a must
  In gLite, first from the broker, then from execution service

Balazs:
  First mandatory validation, then response containing maybe validation errors
  You have to validate first, to check for errors

Etienne:
  First mandatory validations:  XML, Schema, Semantic,
  Some validation may be only possible later ?

Balazs:
  All validation should be done before, then assign state
  You submit a job, execution service does couple of things like validation
  The first time the submitter can check the state is when he/she has the JobId

Etienne:
  At the beginning, I did not write the second level substates of 'Submitted'.
  I added them after some request, and I am ready to remove them.

Balazs:
  Hold point is important :
  Substate of 'Submitted' which is a 'Hold' !

Etienne:
  Concerning the 'Submitted:Hold' substate, I sent a mail on 13 August

Balazs:
  changeState operation
  resume like operations
  andy kind of hold states

Morris:
  We need a figure :
  - not only the state model figure
  - but a step by step base like figure of presentation

Etienne:
  We have to agree on the scope of the 'Submitted' state :
  Inside the 'Submitted' state, as soon a job has its JobId, the job should go to the 'Pre-processing' state, where it 
can be put in a 'Hold' substate

Balazs:
  Is 'Pre-processing' different from data staging ?

Etienne:
  'Pre-processing' includes data staging
  Any other actions can be performed
  That's why there are third...