Test Lab Server Spec

This is a specification the CELF Test Lab Server

VERSION 0.1 - for other versions, click the "info" button.

Table Of Contents:

Introduction

This specification describes the configuration and conventions used for the CELF Open Test Lab server. This includes conventions and interfaces between the server and lab clients, and between the server and lab hosts.

This document is related to the Test Lab Architecture document, where the overall architecture of the lab is described.

Rationale

This specification is needed in order to:

• define the detailed interactions and interfaces between the server and other test lab elements

Definitions

host 

 : A machine used to control or access one or more target boards.

client 

 : A machine used to request lab services

server 

 : The machine that is the central server for the CELF test lab.

Server

The lab server has many distinct roles in the operation of the lab:

• it holds reservations (scheduling) of lab machines for interactive use [I'm still deciding on this one - reservation info could be stored on the host]
• it is a web server with lab information and results publication
• it is a repository for tests and test suites
• it holds information about requested automated tests (test jobs)
• it collates nightly regression test results

Note that the server is almost entirely passive. As can be seen below, the host machines have the major role in initiating test activities as part of automated testing. This more easily allows a single test to be performed at disjoint times. That is, a single test that is targetted at multiple boards run on each target independently. Instead of requiring "gang" scheduling of the targets, this allows much more flexibility in scheduling the job.

Also, the nodes for which a job is request do not need to be "online" (actively connected to the lab or the server) when a test is scheduled, or even when the job is run on other nodes. This makes it possible to request and run jobs on nodes that are only intermittently available to the lab.

Another reason for this is to make it easier to set up automated private testing. If the server initiated testing, it would need an ssh account on the private machine. In a "host-pull" model, only web access to the server is required from the host, which is much easier to configure for private machines (which are often behind strict corporate firewalls).

Use Cases

See Test Lab Architecture for detailed steps for each of the major lab use cases.

Required Interfaces and Capabilities

/\ [ This section is still under construction ]

Desired operations on the host machine

This section describes in simple sentences, the requirements on the server machine. After each statement, in parenthesis, is a possible command that could be used to implement the required operation.

[not written yet.]

Notes (informational and non-normative)

[additional information or clarifying comments]

References

[ pointer(s) to implementation, open source project(s), POSIX specification, etc.]

Related work

[none listed so far]

Remaining Issues

[this is a placeholder section for listing issues while the spec is under development. It should be empty when the spec is completed (or the issues should be deferable to a subsequent version of the spec).]