docs/release/scenario-lifecycle/deployment-options.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 Deployment Options
   7 -------------------
   8
   9 What are deployment options?
  10 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  11
  12 .. Editors note: Some installers call it settings. Prefer options, because it allows
  13 .. cases with multiple options.
  14
  15 During the analysis of scenario definitions in Colorado and Danube releases, it became
  16 visible, that HA and NOHA deployment of otherwise identical scenarios shouldn't be
  17 called different scenarios.
  18
  19 This understanding leads to the definition of another kind of attributes
  20 in scenario definitions. Many scenarios can be deployed in different ways:
  21
  22 * **HA** configuration of OpenStack modules (that is redundancy using multiple
  23   controllers running OpenStack services) versus NOHA with only a single controller
  24   running a single instance of each OpenStack service
  25 * Some scenarios can be deployed on intel and on ARM **hardware**.
  26 * We can see the **installation tools** in the same way. Independent of the installer
  27   that was used for the deployment of a scenario, the same functionality will be
  28   provided and we can run the same testcases.
  29
  30 Please note that a scenario can support multiple deployment options. And a scenario
  31 definition must specify at least one option of each type.
  32
  33 In future there will be more deployment options, e.g. redundancy models or other
  34 clustering options of SDN controllers, or upscaling compute or control nodes.
  35
  36 CI Pipeline needs to test all configuration options of a scenario.
  37
  38 * Development cycles (verify-jobs, daily, weekly) don‘t need to run all
  39   options each time
  40 * Release testing must cover all those combinations of configuration options that
  41   will be part of the release. Typically the HA configurations are released on
  42   bare metal with the allowed hardware options and all installers that can deploy
  43   those. Release of an NOHA option should be an exception, e.g. for a scenarios
  44   that are not mature yet.
  45 * Virtual deployments are not mentioned here. All scenarios should allow virtual
  46   deployment where applicable.
  47   But in release testing, bare metal deployment will be necessary.
  48   CI will use virtual deployments as much as appropriate for resource reasons.
  49
  50
  51 Deployment options or new scenarios
  52 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  53
  54 In general we can say that a different scenario is needed when the set of components
  55 is changed (or in some cases a general deploy-time configuration of a component). If
  56 we deploy the same components in a different way, we can define this via deployment
  57 options.
  58
  59 **Examples**
  60
  61 * Deploying different SDN controller or data plane (OVS/FD.IO) requires different
  62   scenario.
  63 * HA/NOHA will deploy the same components on different number of nodes, so it is a
  64   deployment option.
  65 * Different hardware types should not lead to new scenarios. Typically the same
  66   scenario can be deployed on multiple hardware.
  67
  68
  69 HA and NOHA
  70 ^^^^^^^^^^^^^
  71
  72 Both, HA and NOHA options of a scenario are important.
  73
  74 * HA deployment is important to be released in major OPNFV releases, because
  75   telco deployments typically have strong requirements on availability.
  76 * NOHA deployments require less resources and are sufficient for many use cases.
  77   For instance sandbox testing can be done easier and also automatic verification
  78   in the CI pipeline can make use of it.
  79 * Generic scenarios shall support the HA and NOHA option.
  80 * Specific scenarios can focus on the NOHA option if their features are independent
  81   from the controller redundancy. But before merging with generic scenarios, they
  82   should provide both options.
  83
  84
  85 Hardware types
  86 ^^^^^^^^^^^^^^^^^
  87
  88 In its first releases, OPNFV could be deployed on Intel hardware only. Later, support
  89 for ARM hardware was added and now 5 scenarios can already be deployed on both.
  90
  91
  92 Virtual deployment
  93 ^^^^^^^^^^^^^^^^^^^^^^
  94
  95 Many, but not all scenarios can be deployed on virtual PODs. Therefore the scenario
  96 definition shall specify whether virtual deployment is possible.
  97
  98 Typically a virtual HA deployment shall look very much the same as a bare-metal HA
  99 deployment, that is the distribution of modules on nodes/VMs is similar. But there
 100 might be cases where there are differences. Thus, the scenario specification needs
 101 to provide the data for each separately.
 102
 103
 104 Deployment tools
 105 ^^^^^^^^^^^^^^^^^^^
 106
 107 Deployment tools (installers) are in a very similar relation to the scenarios.
 108 Each scenario can be deployed by one or more installer. Thus we can specify the
 109 installers for a scenario as a deployment option.
 110
 111 However, the installers need additional detailed information for the deployment.
 112 Every installer may not support the same HA, hardware, virtualization options,
 113 or same distribution of modules. Each deployment may look slightly different
 114 per installer.
 115
 116 The scenario definition needs to provide such information in a way it can be easily
 117 consumed by the installers.
 118
 119
 120
 121 Other deployment options
 122 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 123
 124 This set of deployment options is based on what is required by Danube scenarios.
 125 Future releases will most likely introduce additional deployment options.
 126
 127
 128