Discussion of how to do future testing

From ReddNet
Jump to navigation Jump to search
  • 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