Gridforge is not responding so attaching minutes from yesterday's call.
I'll upload the file later.
--
Andreas Savva
JSDL Teleconference - 20 May 2008
==================================
* Participants
Fred Brisard
Donal Fellows
Steve McGough
Alexander Papaspyrou
Andreas Savva
Philipp Wieder
Apologies: Michel Drescher, Shahbaz Memon
* Summary of Actions
ACTION: Philipp will do a first draft of an aggregated list of
requirements
* Activity use case - Job lifecycle tracking
** Requirements
- Job attributes / state changes for entire lifecycle;
- Entering system - to not active
- Not clear if the use case requires the information to stay
around in the system after activity is no longer active
(probably), and if so how long (implementation-dependent).
- [Talk with Chris.]
- Information to track
- initial submission requirements (e.g., jsdl), (Location: BES resource?)
- state changes, incl time
- handover in responsibilties (similar to delegation scheduling
use case)
- recording of who made a decision and what that decision
was
- resource usage during runtime
- final accounting record: summary record perhaps
- summary records are not clearly a part of the usage record
1.0; should probably be separate from the usage record
entry
- Access mechanisms: query while activity is running can be on BES;
or other service afterwards, (maybe what 'file' refers to)
- information when an exception happens (probably related to state
change); and what the exception was
* Fred's description of CA use/usage case
- record of what to execute (e.g., jsdl)
- record of what happens to activity through execution
- state changes captured as individual records
- jobs have problems during execution; and might get rescheduled
(-through third-party products) etc. A common format helps
interoperability
- Administrators need this information for troubleshooting, decision
making, to optimize execution, etc,
- Customer also needs to see this information to see how/if things
work properly
- Historical record helps in estimation of future jobs
- Schema requirements: fixed part where a specification exists
(e.g., initial submission jsdl) plus extensibility for more
private/proprietary information; how far to go either way is a
balancing act
* Summary
ACTION: Philipp will do a first draft of an aggregated list of
requirements
* OGF23 session
- Motivation / Overview of what has been disucssed
- collected use cases
- requirements list
- work on strawman
Invite people who showed interest in the BoF last time: Steven
Newhouse, Andrew Grimshaw. And/or talk to them in advance
Provide skype and glance during the session
