Title: BRT Automation
Author: Judith Lebzelter
Date: October 15, 2005


Purpose:

It has been mandated that BRT should run in an automated mode, 
presumably locally like STP on OSDL hardware.  It makes sense 
that we should use this opportunity to imrove the code base and 
the functionality.  The BRT vision is to make all the parts 
modular and flexible;  It should allow the end tester to chose 
the features wanted for his test and to get the data uploaded 
in the easiest manner for him.  

Below is a brief list of the issues that will be involved in the 
automation.  These will then be addressed individually in more 
detail.



Issues to be addressed:

A. STP changes, how to handle what are they
    * Conversion to PostgreSQL
    * Ruby on Rails
    * Other?
    * STP should be able to run 'lite'?
B. Web Interface for BRT?
C. Automated local Installation for base installations
D. Parameters for test_requests, sub-tests
E. Client Automation
F. Coexistance of Automation/Lite
    * Handle hosts automated/Lite in requesting test
    * Upload data methods
    * Additional tracking
G. Kernel Update Optional for BRT
    * For internal. like STP
    * For external, need base source override in PLM
H. Hardware
I. Data searches should be improved (additional)


Overiew Detail of Issues:

A.  STP Changes:  
The time frame for the completion of the STP conversion to 
postgreSQL is not clear.  Once this is complete we will need
convert BRT to PostgreSQL as well if we do not wish to fork 
STP, which would be undesirable all around.  

---Get more information on STP PostgreSQL conversion

The new web interface for STP is using Ruby on Rails.  This 
adds dependencies (Ruby, Ruby on Rails) for the server side 
but not for the client.  This is for both searches and 
submission of test requests.

If this is as straightforward as Mark says, then we may 
benefit from making a web based test request for for BRT as 
well.

We need to understand any other changes in the works for STP 
before we can set a schedule for this.
---Get more information on STP Plans


B. Web interface for BRT:


C. Automated local Installation for base installations

STP is currently using 'systemimager' for all installations.  This technique 
reimages the host via rsync of a static version that sits on the image server.
Historically, setting up an image has been a tedious process and therefore 
done only infrequently.  However, if the master file can be reused for 
subsequent versions, then maybe it would be an acceptible option.

For BRT the base installation is small, but changes frequently.  This may or 
may not be best done through system imager.  

--->This should be discussed with STP, as I believe they may be planning some 
changes in this area.


D. Parameters for test_requests, sub-tests



E. Client Automation




F. Coexistance of Automation/Lite
    * Handle hosts automated/Lite in requesting test
    * Upload data methods
    * Additional tracking



G. Kernel Update Optional for BRT

For testing internal to OSDL, it seems as though it should be simple 
enough to add a kernel build as an option.  We would require PLM in the build 
set and to make the kernel build optional.

For testing external to OSDL, PLM would either need to start using an external 
mirror of kernel.org, or would need to be modified to allow an Override of the 
URL on a per software basis.


H. Hardware

The server side, data storage, database and bug tracker sections 
remain the same.  

We would require hosts dedicated to being Systems Under Test.  It 
is not currently clear what hosts these would be.  Most of the project machines
are quite out of date, decrepit and are for projects.


I. Data searches should be improved (additional)

This does not truly belong to the heading 'automation'; however, if 
we are working on a web interface it may be practical to include 
some data searching improvements.