VEGAS Project Meeting - Test Environment Review: 2017 February 9th 10:00 - 11:00am ET

Present

• Ryan, Randy, Laura, Jason, Joe, Ray, Richard

Purpose

Minutes

• Test environment was requested in a project overview
• System was costed and hardware has been bought/built and will be installed in equipment room imminently
• Currently plan to use vegas-hpc10 (a spare HPC)
  • Ray currently uses this for BTL testing
  • Will be networked throught the BTL switch (currently also used for VEGAS) so this should not prevent any further use for BTL testing
• Project document specifies that the test environment will consist of a ROACH2, HPC, and switching signal distribution system. It is intended to be a complete replica of a VEGAS HPC bank except for the IF modules. The project document specified that it would run "well-defined software versions, allowing system-wide integration and regression testing".
  • Ray prefers that the test environment be able to act as a development environment.
    • A development environment should have some hardware (not necessarily complete) that will allow for testing software, concepts, performance, and throughput, that is not on the telescope and does not require telescope time to use.
    • In Ray's opinion, this system should have a ROACH2, possibly with an input, one to two compute nodes (as similar as possible to the VEGAS HPCs currently in use), and a fast disk to test throughput.
  • A development environment would be dedicated for development, and would not be used for debugging released software.
    • Ryan asks if we could have the equivalent of a '/home/gbt' (but not actually using the real telescope) which would have a complete installation of the current release version, and a development environment?
      • Ray and Joe say this can be done but the important thing is to have exclusive access to hardware so that development work is not interrupted.
• Jason thinks the system that is being assembeled is consistent with what Ray and Joe desire.
  • The one caveat is that it doesn't have a dedicated input, which may sometimes be needed.
• Ray and Joe prefer having a mostly dedicated software development environment that they would control access to.
• Ryan asks if this system could be used to test a release candidate once it is ready
  • It sounds like the answer is yes, but by that point the release candidate would hopefully be ready for true regression testing
• It sounds like the conflict is that the original scope called for (perhaps implicitly) a complete simulation of the release envrionment. Ray and Joe do not want to have to maintain that and risk having other users interrupt their work for non-development work.
• Ryan asks if srbs can be used to accomplish what Richard wanted the test environment to do?
  • It might need a new fast disk (perhaps a SSD RAID)
  • A second HPC node (srbs-hpc1 and srbs-hpc2) with hardware and architecture as similar as possible to the target environment. This would be a clone (as close as possible) of the current srbs-hpc1
  • 10-gigE network between the ROACH and the second HPC node. The current ROACH has 4 outputs, so that is sufficient. Direct connect would be sufficient - no need for a switch.
  • A second ROACH2 so that different modes could be tested simmultaneously. This would require a switch.
  • What we need
    • A second ROACH2
    • Possibly: A machine that could become srbs-hpc2 with the appropriate hardware and architecture
    • A switch if we put the development environment in the tape room. If we put the development environment in the equipment room, we could use the BTL switch.
• If the test environment was put in the tape room, it would not be on the same network as everything else in the equipment room. It would also not have access to the real switching signal distribution system. Is this a deal breaker for the test environment?