docs/scenario-lifecycle/creating-scenarios.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 Creating Scenarios
   7 --------------------
   8
   9 General
  10 ^^^^^^^^^
  11
  12 A new scenario needs to be created, when a new combination of upstream
  13 components or features shall be supported, that cannot be provided with the
  14 existing scenarios in parallel to their existing features.
  15
  16 Typically new scenarios are created as children of existing scenarios.
  17 They start as specific scenario and as they mature, they either merge back
  18 their features to the parent or promote to a generic scenario.
  19
  20 Scenario Owners
  21 ^^^^^^^^^^^^^^^^
  22
  23 Each scenario must have an "owner". Scenario owners have the following responsibilities:
  24
  25 * The scenario owner is responsible for the contents and usage of the scenario.
  26 * He shall define the contents for the scenario deployment:
  27
  28   * The components and their versions that need to be deployed
  29   * Options for the deployment of such components, e.g. settings, optional features, ..
  30   * Which installers to use
  31   * Deployment options (HA, NOHA, hardware types, ..)
  32
  33 * He shall define the usage of the scenario in the development process:
  34
  35   * Initiate integration to CI
  36   * Define which testcases to run
  37   * Applies that the scenario joins a release
  38
  39 * The owner maintains the Scenario Descriptor File (SDF)
  40 * Drives for the scenario be supported by more installers
  41
  42 The scenario owner of a specific scenario typically comes from the feature project
  43 that develops the features introduced by the scenario.
  44
  45 The scenario owner of a generic scenario will need to drive more integration tasks than
  46 feature development. Thus he typically will come from a project with a broader scope
  47 than a single feature, e.g. a testing project.
  48 The scenario owner of a generic scenario needs to cover issues of all installers, so
  49 only in exceptional cases he will come from an installer project.
  50
  51 Creating Generic Scenarios
  52 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  53
  54 Generic scenarios provide stable and mature deployments of an OPNFV release. Therefore
  55 it is important to have generic scenarios in place that provide the main capabilities
  56 needed for NFV environments. On the other hand the number of generic scenarios needs
  57 to be limited because of resources.
  58
  59 * Creation of a new generic scenario needs TSC consensus.
  60 * Typically the generic scenario is created by promoting an existing specific
  61   scenario. Thus the only the additional information needs to be provided.
  62 * The scenario owner needs to verify that the scenario fulfills the above requirements.
  63 * Since specific scenarios typically are owned by the project who have initiated it,
  64   and generic scenarios provide a much broader set of features, in many cases a
  65   change of owner is appropriate. In most cases it will be appropriate to assign
  66   a testing expert as scenario owner.
  67
  68 Creating Specific Scenarios
  69 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  70
  71 As already stated, typically specific scenarios are created as children of existing
  72 scenarios. The parent can be a generic or a specific scenario.
  73
  74 Creation of specific scenarios shall be very easy and can be done any time. However,
  75 support might be low priority during a final release preparation, e.g. after a MS6.
  76
  77 * The PTL of the project developing the feature(s) or integrating a component etc can
  78   request the scenario (tbd from whom: CI or release manager, no need for TSC)
  79 * The PTL shall provide some justification why a new scenario is needed.
  80   It will be approptiate to discuss that justification in the weekly technical
  81   discussion meeting.
  82 * The PTL should have prepared that by finding support from one of the installers.
  83 * The PTL should explain from which "parent scenario" (see below) the work will start,
  84   and what are the planned additions.
  85 * The PTL shall assign a unique name. Naming rules will be set by TSC.
  86 * The PTL shall provide some time schedule plans when the scenario wants to join
  87   a release, when he expects the scenario merge to other scenarios, and he expects
  88   the features may be made available in generic scenarios.
  89   A scenario can join a release at the MS0 after its creation.
  90 * The PTL should explain the infrastructure requirements and clarify that sufficient
  91   resources are available for the scenario.
  92 * The PTL shall assign a scenario owner.
  93 * The scenario owner shall maintain the scenario descriptor file according to the
  94   template.
  95 * The scenario owner shall drive the necessary discussions with installers and testing
  96   teams to get their support.
  97 * In case the scenario needs new keywords in the SDF, the scenario owner shall discuss
  98   those with the installer teams and CI.
  99 * The scenario owner shall initiate the scenario be integrated in CI and
 100   participate in releases.
 101 * When the scenario joins a release this needs to be done in time for the relevant
 102   milestones.
 103
 104