• In addition to exitcode, raw exit status will also be populated. For the queries only exit status will be used.
• For multicore job calculations there should be a multiplier factor associated in the schema. The multiplier factor will be provided by the users in the DAX and propagated by Pegasus to the submit files for monitord to pick up.
• CPU Time tracking in addition to the walltime ( as currently reported by kickstart ). According to Jens utime is in the kickstart record

After talking to Monte about schema changes, here are things that we agreed to

1) pegasus tools ( statistics , plots and analyzer ) will work across versions

• with a 3.2 tool, one can still query 3.1 database ( upgraded to include the new schema info table . no existing tables altered ). this is where the retrieval api will have to issue different queries based on schema version.
• with a 3.1 tool, one can query a 3.2 database. but this does not make much sense. this is only possible because for 3.2 we are adding columns not removing.

2) monitord from pegasus version 3.2 in replay mode, can convert 3.1 logs to a 3.2 format

• monitord from a 3.2 version cannot write to a 3.1 database, unless the database is separately upgraded (complete upgrade ) or recreated. nl loaders schema detection code will be in the loader module.

3) upgrade schema tool.

• in the mysql case we may get error if user has write permission but no alter table /create table permission. this is because sql alchemy always tries to add new tables in the schema definition file if it does not exist.
• one case will do a partial upgrade. that is only add the schema info table.
• complete upgrade ( that is alter existing table and add schema table ) . Makes sense for a mysql database, where then monitord is replayed to populate the contents. The upgrade tool itself will not be able to add missing values for the new columns in existing tables.