Differences

This shows you the differences between two versions of the page.

--- opnfv_testbed_infrastructure [2014/11/25 14:28]
Morgan Richomme
+++ opnfv_testbed_infrastructure [2015/01/13 16:29]
Wenjing Chu
@@ Line 1: / Line 1: @@
 ==== OPNFV Project Proposal: Testbed Infrastructure ====
-Version: 1.0 (Nov 24, 2014)
+Version: 1.0 (Dec 2, 2014)
 **Project Name: **
-Faros or TBD
+Codename: Pharos
+Descriptive name: Test-bed Infrastructure
 **Project repository:**
-opnfv-repo-faros or opnfv-repo-tbd
+pharos
 **Project Categories:**
-    * Documentation
     * Integration & Testing
-    * Collaborative Development
 **Project Description**
-This project is the combination of three work threads: testbed governance and policy, reference platform hardware and software definition, and platform tooling. We plan to submit the combined project as a single proposal to TSC.
+This project proposes developing a test-bed framework for creating a federated NFV test capability that will be hosted by a number of companies in the OPNFV community. We have at least 1 volunteer party in each of Asia, Europe and US at this time. The volunteer parties will be responsible to setup, operate, and maintain these test-beds in a way that is consistent with the proposed OPNFV test-bed framework.
+{{ :opnfv-test.jpg?600 }}
 There are many reasons that community testbeds are important resources to the success of the OPNFV mission. Here are just to name a few (and by no means exhaustive):
-  * For the broad community to be able to understand, evaluate and try/adopt to use OPNFV's output (e.g. an OPNFV release), we need an open, consistent, repeatable/replicatable reference testbed environment.
+  * For the broader community to be able to understand, evaluate and adopt OPNFV's output (e.g. an OPNFV release), the OPNFV community needs to first collectively test OPNFV ingredients and platforms with realistic NFV use-cases by using an open, consistent, repeatable/replicatable test environment.
-  * While some of development, testing, benchmarking and use case work may be completed in a simple dev environment, many complex and scale cases require more substantial resources not easily available to an average developer. OPNFV does not plan to own and operate such an infrastructure at this time. Community testbeds are necessary.
+  * While some of development, testing, benchmarking and use case work may be completed in a simple dev environment, many complex and scale cases require more substantial resources not available to many developers. Since OPNFV does not plan to own and operate such an infrastructure at this time, community hosted testbeds are necessary.
-  * Evaluation and adoption of OPNFV is a complicated process. A reference testbed with well-documented hardware and software components can help to significantly simplify this process for the community.
+  * Setup and evaluation of OPNFV technologies and platforms is a complicated process not least because of the significant integration effort required and multitude of configuration options available. A reference implementation running on a test-bed with well-documented hardware and software components, as well as configurations and integration/configuration learnings can help to significantly simplify this process for the community (and hence lower barriers to adoption).
   * Open and consistent testbeds under an OPNFV governance and collaborative model are much more valuable than disjoined testbeds from individual entities.
-This project proposes establishing and operating such an OPNFV Testbed Infrastructure.
 ** Scope **
-  * First, this project is to produce a common entry web interface to community testbeds hosted by different parties. This web entry is to be within OPNFV wiki. It should document common information, status, and guides about the testbeds, including governance and policies.
+Three work threads are proposed for developing and operating the infrastructure and this work will be undertaken by the Test and Performance sub-group ...
+. Test-bed governance and policy
+. Reference platform hardware and software definition
+. Test-bed tooling
-  * In order for the testbeds have some basic commonality and portability (to upper layer software), we will define a reference hardware configuration. We will also initially define a "bootstrap" software configuration to get started, and eventually migrate to use OPNFV release(s) coming out of Continuous Integration (CI) project.
+//Test-bed governance and policy//
+  * First, this project is to produce a common web interface to community test-beds that will be hosted by different companies. This web portal will be accessible from OPNFV wiki as the common entry point.
+  * Web interface should document information about the infrastructures and setups that is common across the various implementations as well as individual variations, including ...
+    * Description of systems (detailed specifications of available compute nodes), test-tools, network topologies, etc.
+    * Status of the test-bed (including scheduled projects) and reservation process
+    * User-guides for accessing the test-bed remotely and getting support
+    * Governance and usage policies (under community control and at discretion of hosting company ... e.g. prioritization of projects, escalation process, ...)
+    * Provide ways for making results of test campaigns on the different testbeds available for sharing and encouraging community involvement through e.g. comments on results and suggestions for further testing.
+//Reference platform hardware and software definition//
+  * In order for the testbeds have some commonality and portability (to upper layer software), we will define a reference hardware configuration. We will also initially define a "bootstrap" software configuration to get started (see [[get_started|Project: Bootstrap/Get started!]] project), and eventually migrate to use OPNFV release(s) coming out of Continuous Integration (CI) project.
   * The basic hardware components of the initial version of the testbeds will likely include (only for illustration of scope): x86 servers of relatively recent architectures, relatively high throughput PCIe, 1G and 10G Ethernet Adaptors, local storage, and 1/10G Ethernet switches.
@@ Line 43: / Line 62: @@
   * The basic software components of the bootstrap version may include (only for illustration of scope): Linux OS, Qemu/KVM, OpenStack, OpenVSwitch.
-  * This project is to produce 1 or more functional OPNFV testbeds. We have at least 1 volunteer party in Asia, Europe and US at this time. The volunteer parties are to create, operate, maintain these testbeds consistent with the common reference and policies.
+//Test-bed tooling//
-  * Finally, this project should also include a minimum "smoke test' set that can be run regularly to maintain basic operational status and report this status in the common wiki page.
+  * This project should include a minimum "smoke test" that can be run regularly to verify basic operational status of the test environment and report this status using the web interface.
-Excluded from this project:
+  * An objectives of the test-bed is to provide a repository for the community to easily store and share test artifacts ... including test workloads (e.g. VNFs), test scripts (e.g. for configuring test-harness components or device under test), traffic profiles, test results, etc.)
-  * Performance benchmarks
-  * Comprehensive functional tests
-  * VNF use case tests and benchmarks
+__Out of scope__:
+The following projects are envisaged to be executed using the proposed test-bed infrastructure, however are not considered integral to this proposal (these will be submitted as a separate project proposal)
+  * Platform performance benchmarking / characterization ... bottoms up approach to understanding performance
+  * VNF deployment testing (NFV use cases) ... tops down approach with focus on functionality and VNF life-cycle management
+  * Carrier Grade Requirements ... class of tests that focus on operational requirements for a Telco environment
 ** Dependencies **
 This project has the following dependencies
-  * Eventually, the software we use will need to be the output of the CI project.
+  * Eventually, the software we use will need to be the output of the [[get_started:get_started_project_proposal|Get Started/Bootstrap]] or [[octopus:project_proposal|CI project]].
   * We may use tools from other OPNFV projects or from other upstream projects.
   * We may use commercial hardware test equipment or non-open-source test software in non-exclusive basis.
@@ Line 66: / Line 90: @@
 ** Committers and Contributors **
-A partial list at this moment:
+Committers:
   * Wenjing Chu, wenjing_chu@dell.com,
   * Morgan Richomme <morgan.richomme@orange.com>,
   * Trevor Cooper, trevor.cooper@intel.com,
+  * Qiao Fu, fuqiao@chinamobile.com
+  * Eugene Yu (yuyijun@huawei.com)
+  * sheng-ann.yu@ericsson.com
+Contributors:
   * C.Donley@cablelabs.com,
   * erica.johnson@iol.unh.edu,
-  * sheng-ann.yu@ericsson.com,
+  * Kuppuswamy, Prabu <Prabu.Kuppuswamy@spirent.com>
-  * Qiao Fu,  fuqiao@chinamobile.com,
+  * Saikrishna M Kotha <saikrishna.kotha@xilinx.com>
 ** Planned Deliverables **
@@ Line 83: / Line 113: @@
   * A set of software tools for users to access the testbeds.
   * Smoke test and tools for running/automating the smoke test.
+  * A repository for storing and sharing test artifacts
 ** Proposed Release Schedule **
-  * Nov 26, 2014: Official project proposal submission to TSC.
+  * Dec 5, 2014: Project proposal submission to TSC.
-  * Completion of the project phase I: Q1 2015, or aligned with OPNFV Release 1.
+  * Completion of the project phase I: Q1 2015, aligned with OPNFV Release 1.
- --- //[[wenjing_chu@dell.com|Wenjing Chu]] 2014/11/24 06:23//
+{{ :test-bed-timeline.png?nolink&900 |}}

Wiki

User Tools

Site Tools

Differences

Page Tools