Discussion of how to do future testing

• need IBP depot code in code repository - long term goal
• but for now keep code on a webpage for download
• private planet lab deployment for tests and experiments, putting up their own depots, ...
• testing... depot hardware?
  • need depots set aside for testing only
  • we need to be able to respond to problems that will arise in next 6 months of activities - FACIT, CMS, TerscaleSuperNova
  • but much of testing can be done on pre-production REDDnet
  • but depot code is stable for now, only bug fixes to that code
  • if we think something might break REDDnet, then we need to be more careful obviously.
  • main point of test depots at VU is to test depot code

• how confident are we that the depots are stable to both LoCI tools and L-Store tools?
  • one concern - did loose one depot at one point during LoCI tools testing
    • Alan believes this was a bad interaction between LoCI and depot, and he has fixed that now.
  • UTK uploaded over 1 TB of data in 10 GB files and warmed each successfully
  • At Vandy, several augments, uploaded 3 TB and then downloaded
  • in aggregate, 4 test depots have handled 100 million depot commands over past week or so.
  • should we set up a test on 4 test depots to "really pound" the depots? What would such a test involve?
  • Alan has some internal specialized tests that try to test specific features.
  • Chris is going to try a test on SFASU depots from UTK/ewok. saturate SFASU 1 Gbs connection and do internal augmenting to hit them even harder. test of depot and warmer. Chris give PR heads up when that happens.

• testing protocol
  • everybody has everyones Skype accounts for rapid information interaction

• proposed tests
  • stress test on SFASU described above
  • what happens when depots start to get full?
    • depots should do low level reclaimation/resource recovery - Dan and Alan will do this test later this week