Add blueprint enrichment to Docs

Issue-ID: DOC-275

Change-Id: Ieb72ee07ab99e0bb869d0f7d2f16d6a06d4cb623
Signed-off-by: Chris Donley <christopher.donley@huawei.com>

2 files changed, 109 insertions, 5 deletions

diff --git a/docs/guides/onap-developer/architecture/blueprint-enr.rst b/docs/guides/onap-developer/architecture/blueprint-enr.rst
new file mode 100644
index 000000000..404f7d0df
--- /dev/null
+++ b/docs/guides/onap-developer/architecture/blueprint-enr.rst
@@ -0,0 +1,100 @@
+ONAP Blueprint Enrichment
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ONAP Beijing release includes four functional enhancements in the
+areas of manually triggered scaling, change management, and hardware
+platform awareness (HPA). These features required significant community
+collaboration as they impact multiple ONAP projects. These features are
+applicable to any use case; however, to showcase them in a concrete
+manner, they have been incorporated into VoLTE and vCPE blueprints.
+
+Manually Triggered Scaling
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Scale-out and scale-in are two primary benefits of NFV. Scaling can be
+triggered manually (e.g., by a user or OSS/BSS) or automatically via a
+policy-driven closed loop. An automatic trigger allows real-time action
+without human intervention, reducing costs and improving customer
+experience. A manual trigger, on the other hand, is useful to schedule
+capacity in anticipation of events such as holiday shopping. An ideal
+scaling operation can scale granularly at a virtual function level (VF),
+automate VF configuration tasks and manage the load-balancer that may be
+in front of the VF instances. In addition to run-time, this capability
+also affects service design, as VNF descriptors need to be granular up
+to the VF level.
+
+The Beijing release provides the initial support for these capabilities.
+The community has implemented manually triggered scale-out and scale-in
+in combination with a specific VNF manager (sVNFM) and demonstrated this
+with the VoLTE blueprint. An operator uses the Usecase UI (UUI) project
+to trigger a scaleing operation. UUI communicates with the Service
+Orchestrator (SO). SO uses the VF-C controller, which in turn instructs
+a vendor-provided sVNFM to implement the scale-out action.
+
+We have also demonstrated a manual process to Scale Out VNFs that use
+the Virtual Infrastructure Deployment (VID), the Service Orchestrator
+(SO) and the Application Controller (APPC) as a generic VNF Manager.
+Currently, the process is for the operator to trigger the Scale Out
+action using VID, which will request SO to spin up a new component of
+the VNF. Then SO is building the ConfigScaleOut request and sending to
+APPC over DMaaP, where APPC picks it up and executes the configuration
+scale out action on the requested VNF.
+
+Change Management
+^^^^^^^^^^^^^^^^^
+
+NFV will bring with it an era of continuous, incremental changes instead
+of periodic step-function software upgrades, in addition to a constant
+stream of both PNF and VNF updates and configuration changes. To
+automatically deliver these to existing network services, the ONAP
+community is creating framework to implement change management
+functionality that is independent of any particular network service or
+use case. Ideally, change management provides a consistent interface and
+mechanisms to manage complex dependencies, different upgrade mechanisms
+(in-place vs. scale-out and replace), A/B testing, conflict checking,
+pre- and post-change testing, change scheduling, rollbacks, and traffic
+draining, redirection and load-balancing. These capabilities impact both
+design-time and run-time environments.
+
+Over the next several releases, the community will enhance change
+management capabilities in ONAP, culminating with a full CI/CD flow.
+These capabilities can be applied to any use case; however, specifically
+for the Beijing release, the vCPE blueprint has been enriched to execute
+a predefined workflow to upgrade the virtual gateway VNF by using
+Ansible. An operator invokes an upgrade operation through the VID
+interface. VID drives SO, which initiates a sequence of steps such as
+VNF lock, pre-check, software upgrade, post-check and unlock. Since
+virtual gateway is an L3 VNF, the specific operations are carried out by
+the SDN-C controller in terms of running the pre-check, post-check and
+upgrade through Ansible playbooks.
+
+Hardware Platform Awareness (HPA)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Many VNFs have specific hardware requirements to achieve their
+performance and security goals. These hardware requirements may range
+from basic requirements such as number of cores, memory size, and
+ephemeral disk size to advanced requirements such as CPU policy (e.g.
+dedicate, shared), NUMA, hugepages (size and number), accelerated
+vSwitch (e.g DPDK), crypto/compression acceleration, SRIOV-NIC, TPM, SGX
+and so on. The Beijing release provides three HPA-related capabilities:
+
+1. Specification of the VNF hardware platform requirements as a set of
+   policies.
+
+2. Discovery of hardware and other platform features supported by cloud
+   regions.
+
+3. Selection of the right cloud region and NFV infrastructure flavor by
+   matching VNF HPA requirements with the discovered platform
+   capabilities.
+
+While this functionality is independent of any particular use case, in
+the Beijing release, the vCPE use case has been enriched with HPA. An
+operator can specify engineering rules for performance sensitive VNFs
+through a set of policies. During run-time, SO relies on the ONAP
+Optimization Framework (OOF) to enforce these policies via a
+placement/scheduling decision. OOF determines the right compute node
+flavors for the VNF by querying the above-defined policies. Once a
+homing decision is conveyed to SO, SO executes the appropriate workflow
+via the appropriate controller.
diff --git a/docs/guides/onap-developer/architecture/onap-architecture.rst b/docs/guides/onap-developer/architecture/onap-architecture.rst
index eae5c75b7..f84d1a132 100644
--- a/docs/guides/onap-developer/architecture/onap-architecture.rst
+++ b/docs/guides/onap-developer/architecture/onap-architecture.rst
@@ -133,7 +133,7 @@ which highlights the role of key new components:
    deployments to Kubernetes-managed cloud environments.
 
 3. ONAP Common Services now manage more complex and optimized
-   topologies\ **. MUSIC** allows ONAP to scale to multi-site
+   topologies. **MUSIC** allows ONAP to scale to multi-site
    environments to support global scale infrastructure requirements. The
    ONAP Optimization Framework (OOF) provides a declarative,
    policy-driven approach for creating and running optimization
@@ -168,6 +168,8 @@ efficiency and platform deployment. In addition, OOM helps enhance ONAP
 platform maturity by providing scalability and resiliency enhancements
 to the components it manages.
 
+|image3|
+
 OOM is the lifecycle manager of the ONAP platform and uses the
 Kubernetes container management system and Consul to provide the
 following functionality:
@@ -176,7 +178,7 @@ following functionality:
    (including multiple clusters, federated deployments across sites, and
    anti-affinity rules)
 
-2. |image3|\ **Configuration -** unified configuration across all ONAP
+2. **Configuration** - unified configuration across all ONAP
    components
 
 3. **Monitoring** - real-time health monitoring feeding to a Consul GUI
@@ -219,7 +221,7 @@ dashboards, as well as hosted application widgets.
 
 The portal provides an SDK to enable multiple development teams to
 adhere to consistent UI development requirements by taking advantage of
-built-in capabilities (Services/ API/ UI controls), tools and
+built-in capabilities (Services/API/UI controls), tools and
 technologies. ONAP also provides a Command Line Interface (CLI) for
 operators who require it (e.g., to integrate with their scripting
 environment). ONAP SDKs enable operations/security, third parties (e.g.,
@@ -532,10 +534,10 @@ interworking with vendor-specific components, including VNFMs, EMSs,
 VIMs and SDN controllers, across Edge Data Centers and a Core Date
 Center.
 
-|image6|
-
 **Figure 7. ONAP VoLTE Architecture**
 
+|image6|
+
 ONAP supports the VoLTE use case with several key components: SO, VF-C,
 SDN-C, and Multi-VIM/ Cloud. In this use case, SO is responsible for
 VoLTE end-to-end service orchestration. It collaborates with VF-C and
@@ -556,6 +558,8 @@ an efficient path to rapid production.
 
 Read the VoLTE Use Case with ONAP whitepaper to learn more.
 
+.. include:: blueprint-enr.rst
+
 Conclusion
 ==========