Title: Assessment of BRT/STP Project Goals Purpose: To assess the actions/time needed to merge the BRT and STP projects. A project is not just a repository of code. It includes the infrastucture of communications and decision making between developers and users as well as, repositories and documentation. These can include wiki, web, email lists, email, bug-trackers, feature requests etc. There should be guidelines provided between project participants about coding style, contribution methods and communications. Also, user inquiries/requests should be answered within specified targets. These mechanisms will need to be merged and maintained for BRT and STP. The BRT database schema is basically an add-on to the STP database schema. Since an STP database schema re-work is underway, BRT will need this re-work as well. The changes are mostly table and column name changes, while the structure remains on the whole the same. This means the code updates will be some renaming. There should however also be updates to the database access in order to take advantage of the new system, especially transactions. Other changes for STP will also need to be incorporated. These include the SOAP queries through a the 'service' command using WSDL rather than the 'request' and some possible RPC changes. Some of this overlaps the Automation Document for BRT. Project Infrastructure: 1. Put STP/BRT code into one repository(?) or at least the same sort of repository, available externally 2. Communications web wiki email blog and planet: connect to OSDL testing planet 3. Can we tie in other tools, like from NFS? Technical Choices/Changes: 1. Port database to postgreSQL/upgrade scripts accordingly. 2. STP Web interface and application server replacements. 3. OS installation Changes System Image partitioning changes. Gentoo automated installation from stage 3, without system wipe. 4. Automation through rsync/external 5. Coexistance of BRT/STP and Automation/'Lite' 6. Consider any data layout changes 7. Hardware Availability Project Infrastructure: 1. Put STP/BRT code into one repository The STP/BRT code should either be in one repository, or at least the same sort of repostory. Access to working code should be available externally and clearly documented. Otherwise, it is too complicated for external developers to get involved. 2. The STP/PLM development web-page is out of date. 3. Set up a project wiki? Technical Choices/Changes: 1. Port database to postgreSQL/upgrade scripts accordingly. 2. STP Web interface and application server replacements. The web interface in Zope has proven to be difficult to set up and impossible to share with people outside OSDL. Therefore it needs to be replaced. Mark has assessed Ruby on Rails for this purpose. This is the most hyped of the application which follow the popular MVC model. It adds the dependencies to STP of Ruby and Rails. Additionally, the necessity of learning Ruby to get beyond very basic object-relational database calls. A perl based MVC application called Catalyst seems to have a decent following, as well. Additionally, stp_server.pl, which is currently a CGI, may be replaced with and application/service. 3. OS installation Changes System Image partitioning changes. The current image setup has all of the initial image apart from /boot as a single partition. This is a problem because if the root filesystem fills up recovery is difficult (or impossible). Gentoo automated installation from stage 3, with or without system wipe. Possibilities include: - create an image and master file for each stage 3 installation and use systemimager negative: storage space and continuing maintenance (new master file and image creation) - use systemimager to install any generic image, and then install from there - could install on same or separate partition - ??? how do we get the info for the right gentoo stage 3 to install - can we pass systemimager a parameter defining which tarball to pull over? - or do we create a new master file for each base install? - or do we install as a separate BRT command - part of the upgrades but after you've already installed from the generic image? - write a custom installation script instead of using system imager It's not obvious at this point which of the above is the best option or if we've missed something else. More research and discussion is needed. 4. External/Internal Automation through rsync Currently, BRT clients must * have the XML data files locally * be kicked off manually * have no communication with the server while running. The new model would allow the same process or another 'automated' option. The process is as follows: * When a test request is registered, the info for the test is written to the external files server under a directory for the host. * The client configuration should say whether or not to automatically retrieve the test. * The client starts on a schedule and dies if a client is already running. ( Could we supress this once a test starts? That might affect performance runs though shouldd be fine for regression. ) * The client checks the file server for any test files. If its find them it begins the test sequence. Otherwise it exits. * If the host is remote, external reboot is not possible. Maybe an optional self reboot before the run is a good idea. Also, This polling method could work locally with the external reboot. ** Kernel install could be added as _optional_. ** Build set could be made optional. Instead detect the distribution and then do a dump of packages into the log directory. (In case of upgrades) * Additionally, server can now know the state of the SUT if the SUT can rsync the state back to the server. 5. Make BRT and STP work together(?)/Coexistance of Automation and Lite' Due to a lack of hardware and maintenance manpower, it would be convenient if STP and BRT would run in a single instance. It was not designed this way however as we thought at that point STP was to be phased out and merged into BRT. We need to assess the compatibility of the database tables. The biggest conflicts would appear to be the usage of the 'test' table. which in STP is a simple test and in BRT is a test suite where individual tests are stored in the subtests table. This situation also means the test_request_to_parameter tables is not an effective way to pass parameters. Lastly the metric and sub_test_to_result tables work only for BRT. The stp results are done by the tests and relate back to test_request. There are some STP constraints that need to be made optional for BRT: a kernel patch tag, a timeout for 'Lite'. Also, how do we make understood that some hosts are 'autotest' and others are not and are limited to the owners' 'Lite' usage.? 6. Consider any data layout changes Data should be written directly to the final upload location. This should be configurable (as for BRT). Lastly, we should be using variables instead of location names in order that tests will not need re-works if anything should change. Test execution Location should be configurable as well. The upload of results id closely related to their upload. Results for BRT are archived, compressed, encrypted and mailed in. This was done for the 'Lite' requirement. We would need to resolve how to do this from the automated system. STP does this complicated copy, compress, move and upload individually process which is probably not especially wise to reproduce. 7. Hardware Availability Hardware should work for STP or BRT tests. Also discussed previously was the possibility of adding a state which meant the host was temporarily out of the pool, for other testing use and that showing up on the test-request page. This could allow a host to be used in the 'Lite' mode as well.