SRM testing meeting ------------------- 2011-06-06 Participants: Jean-Philippe, Shaun, Dirk, Patrick, Andrea, Alex. Jean-Philippe said that for DPM S2 is not used and he is not optimistic about the effort required to maintain the code and to add or modify tests. For DPM there is a test suite, very specific to it and hence not usable by others. For DPM they also have tests based on GFAL/lcg_util and the dCache SRM client. They are run every night to test every build. There is no proper framework, just a set of scripts. For a few tests written in C the ccheck framework is used. Alex said that for BeSTMan S2 was never directly used, only from Flavia's service. OSG's SRMTester and a Java test suite (using the BeSTMan client) are used, for functionality tests. It is difficult to add tests to the Java-based test suite. He does not object to start using S2 as a common test suite. Before any release they run also tests using the WLCG clients. Testing failures (aka negative tests) are done using the BeSTMan client. No proper framework is used, tests are just scripts. Shaun said that for CASTOR SRM S2 is indeed run before any release. S2 is used for functional tests and part of concurrent testing, while stress tests are run with an internal client. S2's parallelism is quite useful to find race conditions. Dirk pointed out that scalability testing is not easy to standardize, while functionality testing should be standardized. Patrick said that dCache has their own (simple) tests and they do use S2. He supports the idea of keeping S2, but only if at least the majority of the implementations agree to run it. According to Tigran and Gerd, the effort needed to maintain the S2 framework whould be reasonable. Fixes would be committed to the central Sourceforge repository. Patrick agrees on putting some effort on it. Alex said that he cannot commit to help on the framework without securing some funding, but the general opinion is that very little (if any) would be required from him in this respect. Dirk also agrees on putting some effort in the S2 framework's maintenance, where the priority should be on migrating it to 64-bit. Andrea reported what Riccardo told him privately: the StoRM test suite is not really suitable for everybody as it is specific to StoRM. S2 is still very useful as a compliance test suite and he would agree on running it on a regular basis. He also agrees on a collaborative effort to maintain the S2 framework. Everybody agrees that there is no need for a central test submission service. Testing for the sake of sites is not really in the scope of S2, and it is best served by tools like SAM/Nagios or SRMTester. ACTION: Alex will revive the srm-tester mailing list and clean it up. ACTION: Shaun volunteered to play with Sourceforge to understand how to deal with branches, etc. Everybody agrees that the same S2 test suite version should be used by everybody. ACTION: dCache will commit the changes they made into the central repository after having discussed them with the other SRM developers. ACTION: everybody should make sure they know how to run the S2 test suite. ACTION: ask Flavia for the repository management privileges; if it is not possible, migrate everything to a new repository. ACTION: find a date for another meeting in a ~2 weeks time scale from now. Jean-Philippe would like the S2 parallelism feature to be explained/documented to understand how it can be used.