Table Of Contents:

Last Updated April 5th , 2011

Main Focus

JIRA Task Board

TaskBoard for 3.1

Items for April End

Stampede Related Changes

Notification Support in Pegasus via monitord

Monitord Management [Fabio,Gaurang]

Auxillary Tools to Stampede DB

Monitord Changes [Fabio]

DAX API changes

S3 support [Mats, Karan]

Usability Changes

Condor Common Log Handling?

Open Question

Improve the Condor File IO mode in Pegasus ? Not clear how to do it without going down the staging-sites option.
User experience can be improved, but would be a hack to do it in Pegasus without staging-sites option.

User Guide Reorganization [Bill]

Testing Framework and Testing

People Involved [Jens,Gaurang]

Porting the VM to 3.1.0

People Involved [Karan,Rajiv]

Timeline/ Sequence of changes

For Stampede related changes

  1. Stampede DB schema redesign and then support needs to be implemented by Fabio and Monte.
    1. Original estimate by Fabio for db changes and porting of pegasus-analyzer was end of April.
    2. Depending on scale of schema redesign, this may have to be extended !
  2. Only after that pegasus-analyzer, pegasus-statistics and pegasus-plots can be ported for 3.1.

Notification Related Changes

  1. First monitord needs to be managed
  2. Create input file for monitord containing the notifications for the jobs.
  3. Fabio puts in support for notifications in monitord.

Fabio should first work on monitord to be managed. Then move to stampede changes.
This tells us up front if monitord can do notifications. Assumption is that it is critical to not have missing notifications in case of system crash.
If we are ok with as is approach , then management of monitord is not an issue.

While Fabio works on stampede, we can do the creation of the input file for monitord.

If no major stampede db changes are decided, then following might be feasible