Wiki

• Proposed name for the project: Platform tooling
• Proposed name for the repository: repo-name
• Project Categories: (Documentation, Requirements, Integration & Testing, Collaborative Development)

• High level description of test bed tooling and infrastructure project. We are to support these goals:

1. provide a documented baseline using release candidates of opnfv hw/sw ingredients
2. release testing of OPNFV's official releases
3. provide a "sandbox" for developer testing
4. bottom-up benchmarking & performance testing, all the software and tooling required

• Include any architecture diagrams or specifications

1. The first diagram shows a high level working model for release testing and how this project may interact with other projects

• Describe the problem being solved by project

A well established test bed is a critical resource to achieve opnfv's goals. Among these goals, integration of upstream source distributions, operational tools, other software components, hardware infrastructure, validation tools, well thought out quality assurance, well thought out performance metrics benchmarking,… rely heavily on a well established / well understood test bed.

Many developers may not have either the resources or the time or the inclination to create and maintain such a test bed on their own. It is a substantial challenge to create such an infrastructure in sizable / realistic scale. The well designed / well documented "sandbox" environment can improve developer efficiency and accelerate opnfv's project progress. This benefit can be extended most of the projects.

Benchmarking a network function can be a complex undertaking with many variables. This project focuses on a bottom-up approach and will likely meet the need of another project that focuses on specific ETSI defined use cases from top down.

Test bed infrastructure and tooling project extends to all the SW and HW components needed to establish and operate such a test bed. It should:

1. support both micro/macro level testing, virtual infrastructure level or VNFC or VNF level testing
2. can host multi-origin/multi-vendor VNFs, i.e. compositions of vnfc's
3. support regression, functional, and performance/benchmark testing
4. covers both hw and sw components

The test bed will support the following functionality:

1. Access tools: ID/authentication, onboarding, terms of use
2. Access tools: Web access
3. Access tools: Console access
4. Access tools: Reservation / multi-user/tenant
5. On-boarding of vnf/vnfc tools
6. Test automation tools
7. Devops tools
8. Diagnostic, logging, monitoring tools
9. Test load generators, benchmark tools: sw, hw, open source, commercial
10. Test VNFs, common target or auxiliary VNFs - these VNFCs or VNFs are needed for testing, benchmarking, and for helping developers building their own test scenarios
11. inter-testbed connectivity emulation, if needed
12. stand-alone nfvc connectivity emulation, if needed
13. documentation, api reference, test reports

• Specify any interface/API specification proposed

The following diagram shows the high level reference of the test beds and view of the interfaces:

In high level, the interfaces are:

• The interface exposed to an individual developer. This interface is a "user interface".
• The interface exposed to another test bed for virtual interconnect.
• The interface exposed to an emulation test bed, for instance software in a laptop, for virtual interconnect.

For the first release, may be only the "user interface" is required.

• Specify testing and integration:

Release candidates are delivered from CI project. We need to work out a release candidate cadence in practice to (i) have stability of the test bed for developers who rely on a stable environment, and (ii) meet the need of testing the latest release candidate. A suitable cadence needs to be worked out, or a rolling scheme.

More complex NFV use cases may be built on the top of this test bed platform. Those use cases may have separate projects / subgroups dedicated to each of them. Additional tooling may be required for specific use cases. But commonly shared test tooling should all be included in this project.

Some of the testing and benchmarking may be significantly expedited or improved if we can leverage commercial products, either SW and HW. In these cases, some software tools may be required to make the resource available for shared use.

• Debugging and Tracing

Debugging and tracing are part of main deliverable for all in scope testing/benchmarking.

• Unit/Integration Test plans

Test plans of platform level and tool level instrumentation will be covered in this project. It is assumed that a sister NFV use case project(s) will produce higher level use cases in a top-down approach.

• Client tools developed for status shows etc.

Covered in this project includes tools that may go to a developer's client, e.g. for emulation of certain network connectivity. Most of other "client" tools may be supported with web UI.

• Identity a list of features and functionality will be developed.

See above in "Scope" section.

• Identify what is in or out of scope. So during the development phase, it helps reduce discussion.

TBD

• Describe how the project is extensible in future

TBD

• Specify testing and integration like interoperability, scalability, high availablity
• What QA and test resources will be available?

• API Docs
• Functional block description

• Identify similar projects is underway or being proposed in OPNFV or upstream project
• Identify any open source upstream projects and release timeline.
• Identify any specific development be staged with respect to the upstream project and releases.
• Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.
• If project is an integration and test, identify hardware dependency.

• Name of and affiliation of the maintainer: Wenjing Chu (Dell)
• Names and affiliations of the committers
• Any other contributors

• Described the project release package as OPNFV or open source upstream projects.
• If project deliverables have multiple dependencies across other project categories, described linkage of the deliverables.

• When is the first release planned?

This will be part of the first release.

• Will this align with the current release cadence?

Yes.