diff options
author | 2018-10-23 19:02:17 +0000 | |
---|---|---|
committer | 2018-10-23 19:02:17 +0000 | |
commit | e837d81bbbac7f187031e9a98e9d7d23167883f5 (patch) | |
tree | 890c4cd2755d54e74c3d4004543bab098686ae60 /docs/Chapter4 | |
parent | 59a45da4f3aabc2437a437a4ead18feb9d5b4a27 (diff) | |
parent | 037512ad79639516f0bcd772b6080fe8ba28ff5e (diff) |
Merge "VNFRQTS - Fix incorrect metadata usage"
Diffstat (limited to 'docs/Chapter4')
-rw-r--r-- | docs/Chapter4/Modularity.rst | 20 | ||||
-rw-r--r-- | docs/Chapter4/Resiliency.rst | 2 |
2 files changed, 11 insertions, 11 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 diff --git a/docs/Chapter4/Resiliency.rst b/docs/Chapter4/Resiliency.rst index ab188d6..a61bd01 100644 --- a/docs/Chapter4/Resiliency.rst +++ b/docs/Chapter4/Resiliency.rst @@ -128,7 +128,7 @@ Avoid performance-sapping data center-to-data center replication delay by applying techniques such as caching and persistent transaction paths - Eliminate replication delay impact between data centers by using a concept of stickiness (i.e., once a client is routed to data center "A", -the client will stay with Data center “A” until the entire session is +the client will stay with Data center "A" until the entire session is completed). Minimize Cross Data-Center Traffic Requirements |