diff options
author | 2018-10-23 13:05:15 -0500 | |
---|---|---|
committer | 2018-10-23 18:31:52 +0000 | |
commit | 037512ad79639516f0bcd772b6080fe8ba28ff5e (patch) | |
tree | 1cc8082d846e67107fc20e25e2db236e4ce48f72 /docs/Chapter4/Modularity.rst | |
parent | 3558e4ae816958ead70d2032426ec09ae66b5fd0 (diff) |
VNFRQTS - Fix incorrect metadata usage
Change-Id: Ic1cd85ae2afc5f3443f78365789228660fc8c3a2
Issue-ID: VNFRQTS-477
Signed-off-by: Lovett, Trevor <trevor.lovett@att.com>
Diffstat (limited to 'docs/Chapter4/Modularity.rst')
-rw-r--r-- | docs/Chapter4/Modularity.rst | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/docs/Chapter4/Modularity.rst b/docs/Chapter4/Modularity.rst index 6372342..157dccb 100644 --- a/docs/Chapter4/Modularity.rst +++ b/docs/Chapter4/Modularity.rst @@ -27,8 +27,8 @@ ONAP VNF Modularity Overview With VNF Modularity, a single VNF may be composed from one or more Heat Orchestration Templates, each of which represents a subset of the -overall VNF. These component parts are referred to as “\ *VNF -Modules*\ ”. During orchestration, these modules are deployed +overall VNF. These component parts are referred to as "\ *VNF +Modules*\ ". During orchestration, these modules are deployed incrementally to create the complete VNF. A modular Heat Orchestration Template can be either one of the following @@ -82,7 +82,7 @@ ONAP supports a modular Heat Orchestration Template design pattern, referred to as *VNF Modularity.* With this approach, a single VNF may be composed from one or more Heat Orchestration Templates, each of which represents a subset of the overall VNF. These component parts are -referred to as “\ *VNF Modules*\ ”. During orchestration, these modules +referred to as "\ *VNF Modules*\ ". During orchestration, these modules are deployed incrementally to create the complete VNF. A modular Heat Orchestration Template can be either one of the following @@ -94,8 +94,8 @@ types: 3. Cinder Volume Module -A VNF must be composed of one “base” module and may be composed of zero -to many “incremental” modules. The base module must be deployed first, +A VNF must be composed of one "base" module and may be composed of zero +to many "incremental" modules. The base module must be deployed first, prior to the incremental modules. ONAP also supports the concept of an optional, independently deployed @@ -174,8 +174,8 @@ b. Incremental modules for incremental scaling units ii. May be separated by VM type for multi-dimensional scaling -With no growth units, Option 2 is equivalent to the “One Heat Template -per VNF” model. +With no growth units, Option 2 is equivalent to the "One Heat Template +per VNF" model. Note that modularization of VNFs is not required. A single Heat Orchestration Template (a base module) may still define a complete VNF, @@ -193,13 +193,13 @@ There are some rules to follow when building modular VNF templates: a. Must include all shared resources (e.g., private networks, server groups, security groups) - b. Must expose all shared resources (by UUID) as “outputs” in its + b. Must expose all shared resources (by UUID) as "outputs" in its associated Heat template (i.e., ONAP Base Module Output Parameters) c. May include initial set of VMs - d. May be operational as a stand-alone “minimum” configuration of the + d. May be operational as a stand-alone "minimum" configuration of the VNF 2. VNFs may have one or more incremental modules which: @@ -221,7 +221,7 @@ There are some rules to follow when building modular VNF templates: ii. must not be dependent on other Add-On VNF Modules e. Multiple instances of an incremental Module may be added to the - same VNF (e.g., incrementally grow a VNF by a fixed “add-on” + same VNF (e.g., incrementally grow a VNF by a fixed "add-on" growth units) 3. Each VNF Module (base or incremental) may have (optional) an |