Testbed Portal System Requirements¶

Introduction¶

The Testbed Portal is a publicly visible web site that allows users to define OMF experiment scripts, and then run those scripts on the NICTA testbed network. The Portal records properties of each run of an experiment, such as the script (and any dependencies), the parameters, the resources used, the location of the measurements database, and so on, to aid in reliably repeating experiments and auditing what experiments were run. The Portal system also includes a Resource Discovery and Reservation subsystem whose purpose is to provide a reservation system for testbed users, such that users can reserve time on the testbed, and optionally ask the Portal to automatically run a specific experiment during the reserved time period.

Scope & Purpose¶

This document gives an overview of the components of the Portal system, describing in outline their function. The Portal interacts with existing OMF components in order to run experiments and obtain the experiment outcome data. This document gives system-level requirements for both the Portal itself and for the OMF components that must be modified to interact with the Portal. Detailed requirements for the Portal web interface have been provided in another document (need link). The web interface is partially implemented. This document focuses on the requirements of the back-end components (including changes to existing components) in order for a user to run an experiment (either immediately or scheduled at a time in the future) and for the portal to register the experiment script, the experiment run, and the experiment run outcome data.

This document describes requirements and architecture only for the command-line driven user scenario. Other user scenarios will be included in a later version.

This documents assumes some familiarity with the concepts of OMF itself.

Overview¶

There are two main user scenarios:

1. The user runs an experiment from the OMF command line (CLI)
2. The user runs (or schedules) an experiment using the Portal Web Interface (PWI).

This document addresses the CLI scenario. The PWI scenario will be considered in a later version. Here is a diagram of the components and interfaces that play a role in the CLI scenario:

The interfaces are labelled with abbreviations of the two endpoints, with the initiator of the communication on that interface first.

The Portal block represents both the Redmine-based website and its database, together with any other components providing services relating to the information stored in the Portal database. The Portal provides users a web view of scripts and experiment runs. The scripts themselves are stored in the Repository, which may be hosted on a separate machine to the Portal, or on the same machine. The Portal web site provides an interface for viewing, adding, and editing scripts. When the user wants to run an experiment script run, he/she uses the Experiment Controller on the command line to run a particular script with a particular set of properties. When it starts up, the EC communicates with the Repository to access the requested script, and with the Portal to authenticate access to the testbed resources (via the Resource Discovery & Reservation (RDR) block), and to register the experiment run with the Portal. The EC then runs the experiment on the testbed, and stores metadata about the experiment in the OML database. At the end of the experiment, the EC sends experiment outcome data (including URI to the measurements database, metadata, and authentication information) back to the Portal. The portal stores the experiment outcome information against the experiment run entry in its database.

The RDR component maintains a schedule of reservations of testbed resources, and provides a search function that finds new reservations matching user-specified criteria. For instance, a user might request a reservation of the whole testbed for two hours, starting as soon as possible; or a user might request a reservation of any four nodes for one hour at any time in the future; or eight specific nodes for three hours, starting immediately. To know what resources exist on the testbed, it must query the Aggregate Manager (AM). The AM may also ask the RDR what reservations exist at the current time. The RDR must ultimately be able to perform the same function for multiple testbeds, thus it must communicate with multiple AM's. It must also potentially be able to service reservation requests involving multiple testbeds.

The RDR component does not yet exist, however, requirements relating to the reservation function have impact on other components in the system, so they must be considered in this document. The Portal component is a new component that has already been partially implemented (see PortalDesign). The Repository component does not yet exist, but must be developed as part of this project. The EC, AM, and OML Server components are existing components that must be modified to participate in the Portal system.

Interfaces¶

The interfaces shown on the overview diagram are listed in the following table. Note that the overview diagram does not show all of the existing interfaces, only those that are relevant to the portal system. For instance, there is significant communication between the EC and the AM during routine OMF operation, but this is not relevant to the Portal so it is not shown. It is envisaged that most of the interfaces will be implemented as HTTP/REST interfaces, because they only involve client/server style, point-to-point communication. The Interfaces P-R and EC-R will use the same concrete interface exposed by the Repository for manipulating script files.

Interface	Transport	Initiator	Target	Description
P-RDR	HTTP	Portal	RDR	Interface for the portal to request a reservation of a set of resources, and receive either a denial or a time slot and list of resources granted.
R-P	??	Repository	Portal	Repository sends file commit metadata to the Portal Redmine site every time a file is updated in the repository.
P-R	HTTP	Portal	Repository	Interface for Portal to manipulate script files in the repository. This includes asking for a version of a script, updating a script to a new version, adding new scripts
EC-R	HTTP	EC	Repository	The EC also needs to be able to add, update, and read files in the repository. This interface is the same as P-R.
CLI	N/A	User	EC	The OMF command line interface.
EC-OML	HTTP	EC	OML Server	Interface for EC to store metadata in an experiment's measurement result database.
RDR-AM	HTTP	RDR	AM	Interface for RDR to query the AM to know what resources exist on the testbed, as input to the reservation scheduling algorithm.
AM-RDR	HTTP	AM	RDR	Interface for the AM to check for any current reservations on the testbed.

These interfaces will be defined in further detail as part of the requirements given in the following sections.