diff options
Diffstat (limited to 'docs/scenario-lifecycle')
| -rw-r--r-- | docs/scenario-lifecycle/create-sdf.png | bin | 0 -> 402973 bytes | |||
| -rw-r--r-- | docs/scenario-lifecycle/creating-scenarios.rst | 60 | ||||
| -rw-r--r-- | docs/scenario-lifecycle/current-status.rst | 51 | ||||
| -rw-r--r-- | docs/scenario-lifecycle/index.rst | 2 | ||||
| -rw-r--r-- | docs/scenario-lifecycle/pdf-and-sdf.png | bin | 0 -> 189523 bytes | |||
| -rw-r--r-- | docs/scenario-lifecycle/scenario-tree-danube.png | bin | 0 -> 80299 bytes | |||
| -rw-r--r-- | docs/scenario-lifecycle/workflows.rst | 70 |
7 files changed, 143 insertions, 40 deletions
diff --git a/docs/scenario-lifecycle/create-sdf.png b/docs/scenario-lifecycle/create-sdf.png Binary files differnew file mode 100644 index 0000000..c8a44ba --- /dev/null +++ b/docs/scenario-lifecycle/create-sdf.png diff --git a/docs/scenario-lifecycle/creating-scenarios.rst b/docs/scenario-lifecycle/creating-scenarios.rst index f445a00..dbff9c1 100644 --- a/docs/scenario-lifecycle/creating-scenarios.rst +++ b/docs/scenario-lifecycle/creating-scenarios.rst @@ -6,40 +6,47 @@ Creating Scenarios -------------------- -Purpose -^^^^^^^^^^^ +General +^^^^^^^^^ A new scenario needs to be created, when a new combination of upstream components or features shall be supported, that cannot be provided with the existing scenarios in parallel to their existing features. Typically new scenarios are created as children of existing scenarios. +They start as specific scenario and as they mature, they either merge back +their features to the parent or promote to a generic scenario. -* In some cases an upstream implementation can be replaced by a different solution. - The most obvious example here is the SDN controller. In the first OPNFV release, - only ODL was supported. Later ONOS and OpenContrail were added, thus creating - new scenarios. +Scenario Owners +^^^^^^^^^^^^^^^^ - In most cases, only one of the SDN controllers is needed, thus OPNFV will support - the different SDN controllers by different scenarios. This support will be long- - term, so there will be multiple generic scenarios for these options. +Each scenario must have an "owner". Scenario owners have the following responsibilities: -* Another usecase is feature incompatibilities. For instance, OVS and FD.io - cannot be combined today. Therefore we need different scenarios for them. - If it is expected that such an incompatibility is not solved for longer time, - there can be even separate generic scenarios for these options. +* The scenario owner is responsible for the contents and usage of the scenario. +* He shall define the contents for the scenario deployment: -The overlap between scenarios should only be allowed where they add components -that cannot be integrated in a single deployment. + * The components and their versions that need to be deployed + * Options for the deployment of such components, e.g. settings, optional features, .. + * Which installers to use + * Deployment options (HA, NOHA, hardware types, ..) -If scenario A completely covers scenario B, support of scenario B will be -only provided as long as isolation of development risks is necessary. -However, there might be cases where somebody wants to use scenario B -still as a parent for specific scenarios. +* He shall define the usage of the scenario in the development process: -This is especially the case for generic scenarios, since they need more CI and testing -resources. Therefore a gating process will be introduced for generic scenarios. + * Initiate integration to CI + * Define which testcases to run + * Applies that the scenario joins a release +* The owner maintains the Scenario Descriptor File (SDF) +* Drives for the scenario be supported by more installers + +The scenario owner of a specific scenario typically comes from the feature project +that develops the features introduced by the scenario. + +The scenario owner of a generic scenario will need to drive more integration tasks than +feature development. Thus he typically will come from a project with a broader scope +than a single feature, e.g. a testing project. +The scenario owner of a generic scenario needs to cover issues of all installers, so +only in exceptional cases he will come from an installer project. Creating Generic Scenarios ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -80,16 +87,17 @@ support might be low priority during a final release preparation, e.g. after a M a release, when he expects the scenario merge to other scenarios, and he expects the features may be made available in generic scenarios. A scenario can join a release at the MS0 after its creation. - It should join a release latest on the next MS0 6 month after its - creation (that is it should skip only one release) and merge to its parent - maximum 2 releases later. - .. Editors note: "2 releases" is rather strict maybe refine? * The PTL should explain the infrastructure requirements and clarify that sufficient resources are available for the scenario. * The PTL shall assign a scenario owner. * The scenario owner shall maintain the scenario descriptor file according to the template. -* The scenario owner shall initiate the scenario be integrated in CI or releases. +* The scenario owner shall drive the necessary discussions with installers and testing + teams to get their support. +* In case the scenario needs new keywords in the SDF, the scenario owner shall discuss + those with the installer teams and CI. +* The scenario owner shall initiate the scenario be integrated in CI and + participate in releases. * When the scenario joins a release this needs to be done in time for the relevant milestones. diff --git a/docs/scenario-lifecycle/current-status.rst b/docs/scenario-lifecycle/current-status.rst index 08a3776..c8da13a 100644 --- a/docs/scenario-lifecycle/current-status.rst +++ b/docs/scenario-lifecycle/current-status.rst @@ -6,7 +6,8 @@ Current Status --------------- -tdb: this chapter will summarize the scenario analysis. +This chapter summarizes the scenario analysis to provide some background. +It also defines the way to introduce the scenario processes. Arno ^^^^^^^^ @@ -18,31 +19,55 @@ that could be deployed in two ways, by the two installers available in Arno. Brahmaputra ^^^^^^^^^^^^^^^^ -tbd +In Brahmaputra, we added options for SDN (ONOS, OCL) and some optional +features (sfc, sdnvpn, kvm, l3 enabled ODL). +Thus we had 9 scenarios, some of them to be deployed with 2 installers, +that planned to participate in the release. Not all of them succeeded. Colorado ^^^^^^^^^^^^ -tbd +In Colorado more components and features were added to a total of 17 +combinations of components and features. Some were supported by one +of the four installers, others by multiple installers. In addition HA +and NOHA options were defined. +This lead to 28 combinations that planned to participate. Danube ^^^^^^^^^^ -tbd: Analysis of the 58 scenarios -The analysis can be found in the slides at -https://wiki.opnfv.org/display/INF/Scenario+Consolidation -and will be explain with some text here. -The text will also use the diagrams from the slides, e.g. -show a scenario tree: +In Danube the number of combinations of components and features increased +to 24, but since installer support increased and more scenarios planned +to provide HA and NOHA options, the number of combinations was 54. -.. figure:: scenario-tree.png +In addition to that some scenarios were defined later in during development +and some scenarios worked on ARM support. -and an idea about possible generic scenarios: +This created the need to better understand relationships and +incompatibilities of the scenarios to drive for a manageable process +for scenarios. -.. figure:: scenario-tree+idea.png +As a result the relationship between the scenarios can be +visualized by a scenario tree. -as well as possible ways to reach this. +.. figure:: scenario-tree-danube.png +The process for generic and specific scenarios is not in place for the +Danube release yet. But the different branches of the scenario tree +provide the candidates to define generic scenario during the timeframe +of the next release. + +Euphrates +^^^^^^^^^^ + +tbd: statistics on Euphrates Scenarios + +During Euphrates timeframe, dynamic POD allocation is introduced in CI. +This is a prerequisite to make use of the SDF in the CI pipeline. +Therefore in this timeframe, scenario processes are introduced only in +a documentation way and as support for release management. + +Also the definition of generic scenarios can be done. diff --git a/docs/scenario-lifecycle/index.rst b/docs/scenario-lifecycle/index.rst index 36dd92a..c1a9a52 100644 --- a/docs/scenario-lifecycle/index.rst +++ b/docs/scenario-lifecycle/index.rst @@ -21,4 +21,4 @@ Contents: mano-scenarios.rst current-status.rst scenario-descriptor-files.rst - + workflows.rst diff --git a/docs/scenario-lifecycle/pdf-and-sdf.png b/docs/scenario-lifecycle/pdf-and-sdf.png Binary files differnew file mode 100644 index 0000000..729c5a4 --- /dev/null +++ b/docs/scenario-lifecycle/pdf-and-sdf.png diff --git a/docs/scenario-lifecycle/scenario-tree-danube.png b/docs/scenario-lifecycle/scenario-tree-danube.png Binary files differnew file mode 100644 index 0000000..54c111e --- /dev/null +++ b/docs/scenario-lifecycle/scenario-tree-danube.png diff --git a/docs/scenario-lifecycle/workflows.rst b/docs/scenario-lifecycle/workflows.rst new file mode 100644 index 0000000..c07b0f7 --- /dev/null +++ b/docs/scenario-lifecycle/workflows.rst @@ -0,0 +1,70 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) 2017 OPNFV Ulrich Kleber (Huawei) + + +Workflows +---------- + +Summary +^^^^^^^^ + +The general principle can be summarized by the following diagram: + +.. figure:: pdf-and-sdf.png + +Workflows for Scenario Owners +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The scenario owner creates the descriptor file based on the template. + +.. figure:: create-sdf.png + +Create new scenario from scratch ++++++++++++++++++++++++++++++++++++++++++++++++++ + +This workflow will be exceptional. +Most scenarios can easier start as children of an existing scenario; +thus the author (scenario owner) can derive the SDF from the parent. +But scenarios introducing new technologies affecting the whole architecture, +e.g.containers, or higher level scenarios (e.g.MANO and Multisite which +reference existing scenarios) can start without a parent. + +The following steps need to be done: + + #. (Project team) Define set of components that need to be deployed + #. (Project) Find installers that can deploy the components + #. (Project&installer&CI) Agree on new keywords in SDF (e.g. component, feature name) + #. (Project) Assign owner + #. (Owner) Edit SDF, submit to octopus repo + #. (Owner) register scenario to participate in release as appropriate + #. (Owner&CI-team) Adapt jenkins triggers, so new scenario can be scheduled in valid installer/POD/Options combination(s). + #. (Installer-team) test deployment of components + #. (Project-team) Define test cases; register in test db + +Create child scenario by adding feature to existing scenario ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +Add additional installer to a specific scenario +++++++++++++++++++++++++++++++++++++++++++++++++ + +Add additional hardware or availability option to a scenario +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +Merge child scenario back to parent +++++++++++++++++++++++++++++++++++++ + +Promote specific scenario to generic scenario +++++++++++++++++++++++++++++++++++++++++++++++ + +Introduce SDF for existing Danube/Euphrates scenarios +++++++++++++++++++++++++++++++++++++++++++++++++++++++ + + +Workflows for Installers +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Workflows for CI Tools +^^^^^^^^^^^^^^^^^^^^^^^^^^ + + |
