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, using different
  18 upstream open source projects.
  19 In many cases this includes also different upstream projects providing similar or
  20 overlapping functionality.
  21
  22 OPNFV introduces scenarios to define various combinations of components from upstream
  23 projects or configuration options for these components.
  24
  25 The number of such scenarios has increased over time, so it is necessary to clearly
  26 define how to handle the scenarios.
  27
  28 Introduction:
  29 ^^^^^^^^^^^^^^^^^^^
  30 Some OPNFV scenarios have an experimental nature, since they introduce
  31 new technologies that are not yet mature enough to provide a stable release.
  32 Nevertheless there also needs to be a way to provide the user with the
  33 opportunity to try these new features in an OPNFV release context.
  34
  35 Other scenarios are used to provide stable environments for users
  36 that wish to build products or live deployments on them.
  37
  38 OPNFV scenario lifecycle process will support this by defining two types of scenarios:
  39
  40 * **Generic scenarios** cover a stable set of common features provided
  41   by different components and target long-term usage.
  42 * **Specific scenarios** are needed during development to introduce new upstream
  43   components or new features.
  44   They are intended to merge with other specific scenarios
  45   and bring their features into at least one generic scenario.
  46
  47 OPNFV scenarios are deployed using one of the installer tools.
  48 A scenario can be deployed by multiple installers and the result will look
  49 very similar but different. The capabilities provided by the deployments
  50 should be identical. Results of functional tests should be the same,
  51 independent of the installer that had been used. Performance or other
  52 behavioral aspects could be different.
  53 The scenario lifecycle process will also define how to document which installer
  54 can be used for a scenario and how the CI process can trigger automatic deployment
  55 for a scenario via one of the supported installers.
  56
  57 When a developer decides to define a new scenario, he typically will take one
  58 of the existing scenarios and does some changes, such as:
  59
  60 * add additional components
  61 * change a deploy-time configuration
  62 * use a component in a more experimental version
  63
  64 In this case the already existing scenario is called a "parent" and the new
  65 scenario a "child".
  66
  67 Typically parent scenarios are generic scenarios, but this is not mandated.
  68 In most times the child scenario will develop the new functionality over some
  69 time and then try to merge its configuration back to the parent.
  70 But in other cases, the child will introduce a technology that cannot easily
  71 be combined with the parent.
  72 For this case this document will define how a new generic scenario can be created.
  73
  74 Many OPNFV scenarios can be deployed in a HA (high availability) or non-HA
  75 configuration.
  76 HA configurations deploy some components according to a redundancy model,
  77 as the components support.
  78 In these cases multiple deployment options are defined for the same scenario.
  79
  80 Deployment options will also be used if the same scenario can be deployed
  81 on multiple types of hardware, i.e. Intel and ARM.
  82
  83 Every scenario will be described in a scenario descriptor yaml file.
  84 This file shall contain all the necessary information for different users, such
  85 as the installers (which components to deploy etc.),
  86 the ci process (to find the right resources),
  87 the test projects (to select correct test cases), etc.
  88
  89 In early OPNFV releases, scenarios covered components of the infrastructure,
  90 that is NFVI and VIM.
  91 With the introduction of MANO, an additional dimension for scenarios is needed.
  92 The same MANO components need to be used together with each of the infrastructure
  93 scenarios. Thus MANO scenarios will define the MANO components and a list of
  94 infrastructure scenarios to work with. Please note that MANO scenarios follow
  95 the same lifecycle and rules for generic and specific scenarios like the
  96 infrastructure scenarios.
  97