Assessment of STP Client Scripts. Since we want to make the most use possible out of the existing tools we need to do an assessment of their current state and how applicable it will be for BRT. After our planning meeting I have added some of the conclusions we came to to resolve BRT issues. stp_client.pl ------------- The main client script is 'stp_client.pl'. This script is somewhat configurable. The parameter 'use_local_state' when set to 'yes' uses a local file for tracking state rather that the database. However, it seems calls like 'upload_test_results' and 'get_test_request_for_host' do not have local options. Additional customization may be necessary. the running of extra scripts at points, we may use another configuration parameter to turn on 'BRT'. What would be very nice would be if the bulk of the functions in this script were pulled into an OO module, so that BRT could inherit and override a few key methods. I have done a UML diagram towards that end: http://developer.osdl.org/dev/stp/diagrams/stp_client_UML.dia * Linux Kernel The plm scripts are actually configuration items, but this seems to be for the PATH, rather than to give options. The kernel uses 'plm_build_tree.pl' to get source, but the 'robokern' script to build. Additional software uses both 'plm_build_tree.pl' and 'plm_build_app.pl', however since it is optional anyway these will be no problem. * request-details Currently we are exiting if this file exists and does not match the current test_request. This is not what we want for BRT-Lite. * Saving System Info Function 'pre_save_environment' uses '/usr/sbin/lshw' or an application called 'si' to save system information, and FAILS if one does not succeed. The 'post_save_environment' uses 'stp_sysinfo.sh' instead, but it uses the same calls plus 'lspci'. Does our BRT image have these? Do we want to use these or something else? * Test Execution When running wrap.sh a file called 'testEnv.txt' gets sourced. The default file for STP contains: export STP_USER_ENV=no. This could be exploited to customize. Additionally '/usr/bin/stp_include.sh' set up the environment and provides functions to the tests. Logs are hard-coded into '../logs/run-log.txt' relative to the test directory. BRT need to be able to do this part as many times as there are sub-tests. A possible solution is to make the main test tar archive a script which will just unpack and execute all the other tests (and probably move the results around a bit). * Uploading Files Copy and move a lot of files to standard location. Rename .log to .txt. Make a file list, if they are directories tar and compress them (gzip), then bzip and uuencode them (all--directories are compressed twice) and send via SOAP. The test sends e-mail if it cannot upload but does not actually 'FAIL' for this reason. BRT must move all sub-test files after each sub-test. oprofile/*, results/*, /*.html, result_email.txt They should go out of the sub-test directory and into the test directory under the appropriate directories. We must watch the relative paths. Result_email.txt may be problematic, since we only want to send one email with all errors. * Clean Exit Tests must be marked '1' for 'repeat_safe', which is a database column. This is supposed to go only if upload was successful, but I do not see that the script keeps that information. This function removes the directory '/root.last', and moves '/root' to '/root.last', and runs cfengine. Lastly it removes the kernel files. We obviously cannot use this function to clean between sub-tests. * Console Note The function console_note echoes to /dev/console. * BRT Additionally Needs ---------------------- - binapp_set contents--location to retrieve, standard method to install. - build_set contents--packages - sub-tests in the test request. - additional host parameters? - BRT run type: Integration, BAT or BRT. - To update table build_set if it is a BAT or Integration filter. The binapp_set, build_set and sub-tests content sill be dumped to XML consistent with the test-request object. The functions used are XML::Simple for reading and XML::Writer for dumping. Within BRT-Lite if these files are present, we should need no SOAP connection. ( Results can be saved locally on the SUT or another local machine. ) stp_include.sh --------------------- This script provides some environmental variables and and some scripts, generally included in the wrap.sh. It is possible some of the scripts could cause problems. 'DISTRO' is only there for RH and SuSE. It was fixed it to work for gentoo. load_host_modules() uses 'modprobe' which should be fine. Heavy use of relative paths means $WRAP_HOME should be /root/ or we will need to re-work a lot. Most of the functions look like they will cause no problems. stp_robokern ------------- The path to depmod is set by distro. It was fixed. stp_fix-lilo.pl --------------- We are using grub currently. Need to test if this is okay. Not Examined Yet: ------------------- check_system.pl stp_oprofile.sh stp_install_oprofile stp_profile stp_sysinfo.sh mount_disk.pl stp_test_wrap.pl stp_oprofile No Changes Necessary: ------------------------ cleanup.pl - This cleans out the standard results dirs/kernel build stuff. stp_fix-lilo.pl stp_timeout.sh stp_init - ( Not used by Gentoo ) stp_init.gentoo - ( This is already added/tested ) stp_kernel_config stp_sanitize-config - This is just file IO and config stuff stp_state_srv.pl - A listener for the client. Not currently used?