Scalable Test Platform and Patch Lifecycle Manager
STP / PLM Frequently Asked Questions
- Q: What is the Scalable Test Platform?
- Q: What hardware does it run on?
- Q: What is the Patch Lifecycle Manager?
- Q: After a test finishes, how long until the results are available on the web?
- Q: How can we make the results mirror happen more/less often?
- Q: Why don't we run everything on build?
- Q: Why don't we run everything on osdlab?
- Q: What logs are available and on where?
- Q: What processes are run, when and on what machines?
Q: What is the Scalable Test Platform?
Scalable Test Platform is a test harness for building reproducible test environments, executing tests and collecting results.
Q: What hardware does it run on?
It is written in perl, and therefore may run on quite a few architectures, we however have only tested it on i386/Linux. It probably would not run on Windows due to system calls.
Q: What is the Patch Lifecycle Manager?
PLM is as application for tracking base releases and patches to the release, on which you can configure 'filters' to run and store the results. The source trees (base + patches) are then easily available to other plm clients, which we do from STP
Q: After a test finishes, how long until the results are available on the web?
It often takes several minutes for the results to appear on the website, since they're being mirrored by a cronjob that runs once every 5 minutes.
Q: How can we make the results mirror happen more/less often?
STP admins should edit the mirror-results cron entry owned by robot@osdlab to change the mirroring frequency.
Q: Why don't we run everything on build?
Osdlab has a different version of the Perl DBI libraries with functions we need.
Q: Why don't we run everything on osdlab?
We need remote power control & reimage abilities for the stp_cron.pl script. After we get these, we can move stp_cron.pl anywhere.
Q: What logs are available and on where?
The testing platform will capture several logs on the client machine and make them available as part of the test results. Individual tests may also capture additional logs for inclusion in the test results.
The STP framework also produces some logs to indicate its state. In many cases these will be stored in standard locations; for instance, errors related to the web interface will be captured in the Apache error log. /tmp/stp.log is the standard location for STP-specific logs. On client machines, we send a great deal of information to /root/*.log as well as the syslog facility. In the future we hope to provide logging to a central location in such a way that users will be able to view the log messages of any part of the STP framework that touched their request.
Q: What processes are run, when and on what machines?
build.pdx.osdl.net: stp_cron.pl (cronjob by root) osdlab.pdx.osdl.net analyze_queue.pl (cronjob by robot) mirror-results (cronjob by robot) stp_report.pl (cronjob by root)