120 likes | 205 Vues
This testing infrastructure simplifies release management, requiring minimal effort to deploy and maintain. Streamline tools and resources, increase software development quality, support experimentation, and provide custom platforms. The focus is on ongoing development, build and packaging, quality assurance, and supporting various deployment scenarios. The platform allows for full access to developers, easy deployment of monitoring, and centralized management. Automation is key, along with multi-platform testing capabilities and distributed testing options.
E N D
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
Software Development Phases • Experimentation/Prototyping/Demo/Debug • Ongoing development. • Build & Packaging (Release) • Q.A. • Support
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
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
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)
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
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)
Supported Platforms • What makes a supported platform: • Hardware architecture • Operating System and system configuration • Middleware (including language compiler/runtimes) • Network topology
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…)
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.
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