Contents:
Note: This document is still work in progress.
1. Overview¶
1.1. Problem Statement:¶
OPNFV provides the NFV reference platform in different variants, using different upstream open source projects. In many cases this includes also different upstream projects providing similar or overlapping functionality.
OPNFV introduces scenarios to define various combinations of components from upstream projects or configuration options for these components.
The number of such scenarios has increased over time, so it is necessary to clearly define how to handle the scenarios.
1.2. Introduction:¶
Some of the scenarios have a more experimental nature, since they introduce new technologies that are not yet mature enough to provide a stable release. Nevertheless we want to provide the user with the opportunity to test them in an OPNFV release context. Other scenarios OPNFV will stabilize to a certain extend so it is easier for users that wish to build products or live deployments on them.
OPNFV scenario lifecycle process will support this by defining two types of scenarios:
- Generic scenarios cover a set of features provided by different components and target long-term usage.
- Specific scenarios are needed during development to introduce new upstream components or new features.
They are intended to merge with other specific scenarios and bring their features into at least one generic scenario.
OPNFV scenarios are deployed using one of the installer tools. Currently 5 installers are available. A scenario can be deployed by multiple installers and the result will look very similar but not identical. The scenario lifecycle process will also define how we document which installer can be used for a scenario and how the CI process can trigger automatic deployment for a scenario via one of the supported installers.
Many OPNFV scenarios can be deployed in a HA (high availability) or non-ha configuration. HA configurations deploy some components according to a redundancy model, as the components support. These are deployment options of the same scenario.
Some OPNFV scenarios can also be deployed on different types of hardware.
When a developer decides to define a new scenario, he typically will take one of the existing scenarios and does some changes, such as:
- add additional components
- change a deploy-time configuration
- use a component in a more experimental version
In this case we call the already existing scenario a “parent” and the new scenario a “child”.
Typically parent scenarios are generic scenarios, but this not mandated. In most times the child scenario will develop the new functionality over some time and then try to merge its configuration back to the parent. But in other cases, the child will introduce a technology that cannot easily be combined with the parent. For this case this document will define how a new generic scenario can be created.
Every scenarios will be described in a scenario descriptor yaml file. This file shall contain all the necessary information for different users, such as the installers (which components to deploy etc.), the ci process (to find the right resources), the test projects (to select correct test cases), etc.
2. Generic Scenarios¶
2.1. What are Generic Scenarios?¶
tbd: Explain the main characteristics of generic scenarios
2.2. When do we create Generic Scenarios?¶
tbd: Explain circumstances and reason when a generic scenario is needed.
2.3. How do we create Generic Scenarios?¶
tbd: Explain the process for the creation
3. Specific Scenarios¶
tbd: Like the generic scenario chapter, this chapter will describe in detail the characteristics, purpose and process of specific scenarios. (some details are already available in the slides at https://wiki.opnfv.org/display/INF/Scenario+Consolidation, but will here be explained in text). The specific scenarios are used for development of specific features. The relation of parent/child and specific scenarios will be also explained.
4. Parent - Child Relations¶
4.1. What are parent scenarios and child scenarios?¶
tbd: In many cases, development adds a feature to an existing scenario by adding additional components. This shouldn’t be restricted to generic scenarios. Thus also a specific scenario can be used as a parent. This chapter explains this relation and the goal to merge features back from child to parent. This will be illustrated using the pictures from the slide deck at: https://wiki.opnfv.org/display/INF/Scenario+Consolidation
4.2. Siblings¶
tbd: explain the exception that in some cases new scenarios will be created that are not real children, but more like siblings, and will end up in creation of a new generic scenario
4.3. Examples¶
tbd
5. Deployment Options¶
5.1. What are deployment options?¶
tbd
5.2. HA and NOHA scenarios¶
tbd
5.3. Hardware types¶
tbd
5.4. Virtual deployment¶
tbd
5.5. Deployment tools¶
tbd: explain that supported installers of a scenario will be documented like deployment options - even while installers have a more complex role
5.6. Other deployment options¶
tbd: provide some outlook to future opportunities with deployment options, e.g. large deployments. It will be mentioned that these may affece the Pharos spec, so a link to Pharos Change Request process will be added. Other deployment options may need to be supported more generally rather than by having 1 or 2 PODs. This may affect the hardware types section as well.
6. Mano Scenarios¶
tbd: explain how we can handle MANO scenarios, where MANO components should be able to orchestrate all scenarios.
7. Current Status¶
tdb: this chapter will summarize the scenario analysis.
7.1. Arno¶
In Arno release, the scenario concept was not created yet. Looking back, we can say we had one scenario with OpenStack, ODL and KVM, that could be deployed in two ways, by the two installers available in Arno.
7.2. Brahmaputra¶
tbd
7.3. Colorado¶
tbd
7.4. Danube¶
tbd: Analysis of the 58 scenarios
