summaryrefslogtreecommitdiffstats
path: root/docs/Chapter4/Modularity.rst
diff options
context:
space:
mode:
authorLovett, Trevor <trevor.lovett@att.com>2018-10-23 13:05:15 -0500
committerHagop Bozawglanian <hagop.bozawglanian@att.com>2018-10-23 18:31:52 +0000
commit037512ad79639516f0bcd772b6080fe8ba28ff5e (patch)
tree1cc8082d846e67107fc20e25e2db236e4ce48f72 /docs/Chapter4/Modularity.rst
parent3558e4ae816958ead70d2032426ec09ae66b5fd0 (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.rst20
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