docs/scenario-lifecycle/scenario-overview.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3 .. (c) 2017 OPNFV Ulrich Kleber (Huawei)
   4
   5
   6 .. Scenario Lifecycle
   7 .. ==========================================
   8
   9 Note: This document is still work in progress.
  10
  11 Overview
  12 -------------
  13
  14 Problem Statement:
  15 ^^^^^^^^^^^^^^^^^^^
  16
  17 OPNFV provides the NFV reference platform in different variants, where
  18 each variant is called a "scenario".
  19
  20 OPNFV introduces scenarios in order to provide a way to deploy the stack
  21 using different combinations of upstream components, or to provide
  22 different sets of pre-defined configuration options for these
  23 components.
  24
  25 In some cases a scenario is introduced in order to provide isolation of
  26 a specific development effort from other ongoing development efforts,
  27 similar to the purpose of a branch in a code repository.
  28
  29 A certain amount of effort and resources is required in order to include
  30 a scenario in a release. The number of scenarios has increased over
  31 time, so it is necessary to identify ways to manage the number of
  32 scenarios and to avoid that their number grows infinitely. To enable
  33 this, we have to clearly define how to handle the lifecycle of
  34 scenarios, i.e. how to create, how to terminate, etc.
  35
  36
  37 Scenario types:
  38 ^^^^^^^^^^^^^^^^^^^
  39 Some OPNFV scenarios have an experimental nature, since they introduce
  40 new technologies or features that are not yet mature or well integrated
  41 enough to provide a stable release. Nevertheless there also needs to be
  42 a way to provide the user with the opportunity to try these new features
  43 in an OPNFV release context.
  44
  45 Other scenarios are used to provide stable environments for users
  46 desiring a certain combination of upstream components or interested in
  47 particular capabilities or use cases.
  48
  49 The new OPNFV scenario lifecycle process proposed herein will support
  50 this by defining two types of scenarios:
  51
  52 * **Generic scenarios** cover a stable set of common features provided
  53 by different components and target long-term usage and maintenance of
  54 the scenario. Only stable versions of upstream components are allowed to
  55 be deployed in a generic scenario. Across all generic scenarios in a
  56 given OPNFV release, the same version of a given upstream component
  57 should be deployed. Creation of generic scenarios and promotion of
  58 specific to generic scenario requires TSC approval, see section 5.
  59 Generic scenarios will get priority over specific scenarios in terms of
  60 maintenance effort and CI resources.
  61
  62 * **Specific scenarios** are needed during development to introduce new
  63 upstream components or new features. They are typically derived from a
  64 generic scenario and are intended to bring their features back into the
  65 parent generic scenario once they are mature enough. It is also possible
  66 that multiple specific scenarios are merged before bringing them back to
  67 the parent scenario, for example in order to test and develop the
  68 integration of two specific features in isolation. Specific scenarios
  69 can consume unreleased upstream versions or apply midstream patches.
  70 Creation of specific scenarios is not gated, but if a project intends to
  71 release a specific scenario, it has to indicate that in its release plan
  72 at milestone MS1. The scenario itself can be created at any time, by
  73 means of a simple request by a PTL to the release manager.
  74
  75 OPNFV scenarios are deployed using one of the OPNFV installer tools.
  76 Deploying a scenario will normally be supported by multiple installers.
  77 The capabilities provided by the resulting deployments should be
  78 identical. The set of tests to run and their results should be the same,
  79 independent of the installer that had been used. Performance or other
  80 behavioral aspects outside the scope of existing OPNFV tests could be
  81 different.
  82
  83
  84 Parent-child and sibling relations:
  85 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  86
  87 When a developer decides to define a new scenario, he typically will
  88 take one of the existing scenarios and do some changes, such as:
  89
  90 * add additional components
  91 * change a deploy-time configuration
  92 * use a component in a more experimental version or with midstream
  93 patches applied
  94
  95 In this case the already existing scenario is called a "parent" and the
  96 new scenario would be a "child".
  97
  98 Typically parent scenarios are generic scenarios, but it is possible to
  99 derive from specific scenarios as well. it is expected that the child
 100 scenario develops its additions over some time up to a sufficient
 101 maturity, and then merges back to the parent. This way a continuous
 102 evolution of the generic scenarios as well as a manageable overall
 103 number of scenairos is ensured.
 104
 105 In some cases a child scenario will diverge from its parent in a way
 106 that cannot easily be combined with the parent. Therefore, is is also
 107 possible to "promote" a scenario from specific to generic. If this is
 108 foreseeable upfront, the specific scenario can also be derived as a
 109 sibling rather that child.
 110
 111 Promoting a scenario from specific to generic or creating a new generic
 112 scenario requires TSC approval. This document defines a process for
 113 this, see section 5.
 114
 115
 116 Scenario deployment options:
 117 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 118
 119 Many OPNFV scenarios can be deployed in different variants that do not
 120 justify creation of separate scenarios. An example would be HA (high
 121 availability) or non-HA configuration of otherwise identical scenarios.
 122 HA configurations deploy some components according to a redundancy
 123 model. Deployment options will also be used if the same scenario can be
 124 deployed on multiple types of hardware, i.e. Intel and ARM.
 125
 126 In these cases multiple deployment options are defined for the same
 127 scenario. The set of distinguishable deployment option types (e.g.
 128 redundancy, processor architecture, etc.) will be pre-determined and
 129 each scenario will have to define at least one option for each option
 130 type.
 131
 132 It is emphasized that virtual deployments vs. bare-metal deployments are
 133 intentionally not considered as deployment options. This should be a
 134 transparent feature of the installer based on the same scenario
 135 definition.
 136
 137 For generic scenarios, there are certain expectations on the set of
 138 supported deployment options, e.g. a generic scenario should support at
 139 least an HA deployment and preferably both HA and non-HA.
 140
 141
 142 Scenario descriptor file:
 143 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 144
 145 Every scenario will be described in a scenario descriptor yaml file.
 146 This file shall contain all the necessary information for different users, such
 147 as the installers (which components to deploy etc.),
 148 the ci process (resource requirements in order to identify the right pod, machines, etc.).
 149
 150 The scenario descriptor file will also document which installer
 151 can be used for a scenario and how the CI process can trigger automatic deployment
 152 for a scenario via one of the supported installers.
 153
 154
 155 MANO scenarios:
 156 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 157
 158 In early OPNFV releases, scenarios covered components of the infrastructure,
 159 that is NFVI and VIM.
 160 With the introduction of MANO, an additional dimension for scenarios is needed.
 161 The same MANO components need to be used together with each of the infrastructure
 162 scenarios. Thus MANO scenarios will define the MANO components and a list of
 163 infrastructure scenarios to work with. Please note that MANO scenarios follow
 164 the same lifecycle and rules for generic and specific scenarios like the
 165 infrastructure scenarios.
 166