History

Portal Design Meeting

  • DATE: 13/11/2009
  • TIME: 14:00
  • ATTENDEES:
    • Rodney Berriman (RB)
    • Saeed Attar (SA)
    • Thierry Rakatoarivelo (TR)
    • Max Ott (MO)
    • Jolyon White (JW)

AGREED:

  • Max's proposal was discussed, against previous ideas.
    • Version number (major/minor) is a user-controlled artifact; the revision of a particular version is controlled by the repository
    • Most users will not use version numbers. Primary use-case is for dependencies that may change, such as applications and prototypes, and whose versions must be carefully tracked to ensure repeatability of experiments.
  • Need to have a way to know exactly what was run for any experiment run.
    • Therefore, need to record the exact version/revision of all scripts that were run (including dependencies), and enable re-running it ("Force re-run" a particular experiment run).
    • EC recursively loads dependent scripts. EC must be modified to record the dependencies that were loaded. Each loaded script must be checked for latest version in the repository, and checked-in if needed, and the exact version/revision must be recorded in the experiment outcome.
  • The repository can be hosted on a different machine to the Portal, but must still inter-operate with the Portal Redmine site (commit trigger scripts, etc.).
  • Eventually, the Portal will run an EC for the case of scheduled runs. This is for future plans (not currently in scope), depending on XMPP-related development in OMF.
  • Results XML:
    • The XML will be changed to not include the body of scripts. Instead, just the URI of the script and all its dependencies. The top-level script must be made distinct from its dependencies by the XML schema.
    • The start time and finish time/duration are known by the EC. The EC maintains an XML document during run-time; XPath queries can be done at run time, and it also has a built-in web server. Before it shuts down, the EC dumps the XML tree into a file.
    • The Portal should not fetch results direct from the database for the current sprints, but a long-term goal is to have the portal do queries against the measurement results, possibly with a REST interface, so that it can display tables, graphs, etc. of results.

ISSUES:

  • When re-running an experiment, it's unclear how to ask for small modifications to a previous experiment run (e.g. use the new, bug-fixed version of OTG instead of the previous buggy version that caused the experiment to fail).
  • Still unclear how best to implement the repository (e.g. GIT, SVN, CVS, just-use-the-filesystem, etc.).
  • User requirements for the repository are still unclear, but Max's proposal looks like the best starting point.
  • We want to be able to use different views for different trackers.

FOLLOWUP:

  • 1. JW, RB: develop proposal for how to manage force re-running experiments with small changes.
  • 2. SA: start a new Redmine subproject of OMF for the Portal development effort. Use a git repo (JW to assist). Synchronize the git repo to InContext's github repo for the Portal source code.

Meeting closed at 15:21.