1 / 12

perfSONAR testing infrastructure

perfSONAR testing infrastructure. Goals. Provide resources to developer, helping executing the software development phases . Provide infrastructure to simplify release management Requires as little effort as possible to deploy and maintain.

burton
Télécharger la présentation

perfSONAR testing infrastructure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. perfSONAR testing infrastructure

  2. Goals • Provide resources to developer, helping executing the software development phases . • Provide infrastructure to simplify release management • Requires as little effort as possible to deploy and maintain. • Streamline tools & resources across several software initiatives (OSCARS,…). • Increase quality

  3. Software Development Phases • Experimentation/Prototyping/Demo/Debug • Ongoing development. • Build & Packaging (Release) • Q.A. • Support

  4. Experimentation/Prototyping/Demo • Custom platforms (hardware architecture, operating system…) • Custom software (not release, not current) • Custom deployment (number of hosts, network topology) • On demand deployment • Built-in or easy deployment of monitoring • Shared or Private resources • Snapshot, Duplicate, Downloadable

  5. Ongoing Development • Development deployments: • larger deployments than local • third party software (OSCARS,…) deployments • Private or shared (slices) • Must provide full access to developers • Must be breakable/reset-able/duplicable

  6. Build & Packaging • Does not have to be bare iron, VM’s are acceptable • Must contain diverse set of platforms and architectures • Should be automatable • Must be reset-able (clean VMs with each use to eliminate variability) • Should be centralized • Accessible to all developers • Managed (framework should be upgraded over time)

  7. Software Q.A. • Test/Validate release for all platforms • Execute test suite on each platform • Test on different topologies • Allows for distributed testing/validation (LS scalability, inter-op, software update/migration,…) • Automation of all of the above

  8. Issues / Discussion items • Centralized system versus local: do we need a testing environment ? • What should be its scope ? • What are the supported platforms ? • See earlier discussion on support • Virtualization farm: • Existing resources: (NMI, Emulab, etc) • Homebrew (OpenDevNet)

  9. Supported Platforms • What makes a supported platform: • Hardware architecture • Operating System and system configuration • Middleware (including language compiler/runtimes) • Network topology

  10. Existing Infrastructure • NMI: • https://nmi.cs.wisc.edu/ • Built for releasing and testing software • Not designed for extensive network testing (topology, simulation) • Would not support all Arch/OSs for pSPS • Emulab: • https://www.emulab.net/ • Designed for network simulation (topology, interference) • Would not support all Arch/OSs for pSPS • PlanetLab • http://planet-lab.org/ • Distributed computing testbed • Need to worry about scalability of resources • Would not come close to support all Arch/OSs for pSPS • GENI • http://www.geni.net/ • Software can be deployed by itself • Support of federation of test-beds. • Being evaluated for test-beds (ORCA-BEN, ProtoGENI…)

  11. Homebrew • OpenDevNet: • Full control • Initial system is already deployed and used. • Lacks tools, but will benefit of the test-beds development efforf. • May use commercial software (VmWare) • May use Open Source software (GENI…) • Common testing resources with companion projects (OSCARS,…) • Requires resources to operate.

  12. Homebrew 2 (Release only) • Single beefy server • Scripts to generate a series of QEMU/XEN machines • Set the address, use known OS images with necessary developer info • Scripts to automate the build, testing • Destroy VMs after use

More Related