Scenario Lifecycle Document - First version with content
[octopus.git] / docs / scenario-lifecycle / parent-child-relations.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 Parent - Child Relations
7 -------------------------
8
9 In many cases, development adds a feature to an existing scenario by adding additional
10 components. This is called creating a child scenario from a parent.
11
12 * Parent scenarios typically are more stable than children.
13 * Children should plan to merge their feature back to the parent.
14 * Merge back will often add components to the parent.
15
16 .. figure:: parent-child.png
17
18 * Child scenarios can be part of releases.
19 * Child scenarios should merge back to their parent after 2 releases.
20 * If a child scenario lives through several releases, it might be desirable
21   to “rebase/cherrypick” a child scenario to follow changes in the parent scenario.
22 * Child scenarios typically support a smaller number of deployment options than
23   their parent
24
25 Child scenarios are specific scenarios. Parent scenarios can be generic or specific
26 scenarios.
27
28 Child scenarios can be created any time. If they want to join a release, they have
29 to be created before MS0 of that release.
30
31
32 Siblings
33 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
34
35 In some cases it could make more sense to create a sibling rather than a child
36 (e.g. if expected that merging back to parent will be difficult).
37 In other words, the content of a child scenario will be incompatible with content
38 of the parent scenario.
39 In that case, the child scenario should rather become a new branch instead of
40 merging back to the parent.
41
42 .. figure:: sibling.png
43
44 Typically the sibling uses alternate components/solutions than the parent – in
45 long term it might evolve into a new generic scenario, that is a new branch
46 in the scenario tree.
47
48 Creation of the sibling shall not be gated. It should be covered in the scope of
49 an approved project, so there cannot be too big surprises.
50
51 But at a certain time the new scenario will want to change its status from a
52 specific scenario to a generic scenario. This move will need TSC approval.
53 For the application, the scenario owner shall demonstrate that the scenario
54 fulfills the requirements of a generic scenario (see later).
55
56 Examples: SDN controller options, Container technologies, data plane solutions,
57 MANO solutions.
58
59 Please note that from time to time, the TSC will need to review the
60 set of generic scenarios and "branches" in the scenario tree.
61
62