diff options
41 files changed, 119 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 61f0ed196..de921a884 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 ========== diff --git a/docs/index.rst b/docs/index.rst index fbcb897a9..35f17f92c 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -5,6 +5,16 @@ ONAP Documentation ================== +.. note:: + This version of documentation is created from the latest master branch of + source repositories and is not a stable release. + + To get the current stable release use one of the following + + * http://docs.onap.org + * http://docs.onap.org/en/beijing + * the selector on the bottom right and select beijing + .. toctree:: :maxdepth: 2 diff --git a/docs/submodules/aaf/authz.git b/docs/submodules/aaf/authz.git -Subproject 42d6eff8b584adbbe4e9b13fe3244d02723b37c +Subproject 68f3e5a2875f74863b6cbe8eb6dc7138b89668a diff --git a/docs/submodules/aaf/sms.git b/docs/submodules/aaf/sms.git -Subproject baa4e9ffb703f0b93dc8613000e2351ba61dc14 +Subproject 8eb91b97baac63b085a8d75407b85841ff9f444 diff --git a/docs/submodules/aai/aai-common.git b/docs/submodules/aai/aai-common.git -Subproject 986b792c6e6a8896f1f99d08c9519233c2dbdd6 +Subproject 75370173d19e97967d34b3c117f1e3c0820c255 diff --git a/docs/submodules/aai/event-client.git b/docs/submodules/aai/event-client.git -Subproject 385a8bc2de5129126771857bd5d4da11d8b2778 +Subproject 95c897c3c85c305f676dc04adc2f167fecfc598 diff --git a/docs/submodules/aai/sparky-be.git b/docs/submodules/aai/sparky-be.git -Subproject 41a0983d5dd3707b5fd2c86dcc0b4b0c399bd40 +Subproject 3c54febdf3d6e49bd50c7aeca5b4476becfdd02 diff --git a/docs/submodules/appc.git b/docs/submodules/appc.git -Subproject 9ecea5b77482e3a254cedf78e3596468e407381 +Subproject 057c89a2d1db077fa2238c02f998e4dbe9c4726 diff --git a/docs/submodules/appc/deployment.git b/docs/submodules/appc/deployment.git -Subproject 27525d8cce704f03b28eb8833ac1533126ece7d +Subproject cc3142b7f07c697167ace366887acb2836bb48e diff --git a/docs/submodules/ccsdk/distribution.git b/docs/submodules/ccsdk/distribution.git -Subproject 962fc9e71c385f0d08f02002c44e8907d8bf662 +Subproject 6f0c0101dcb421c75a1a49bea02d1dc7479ef7d diff --git a/docs/submodules/ccsdk/parent.git b/docs/submodules/ccsdk/parent.git -Subproject adcb084eebd8ac12837c16ebf58b753fac5864d +Subproject 082e507c45d46642f7ebca886cc944b07475b25 diff --git a/docs/submodules/clamp.git b/docs/submodules/clamp.git -Subproject 6b6521b5824f61dea05f400dba41092f3aaa069 +Subproject 21ebe86d82cb7e7700e45df9873ef5ca1834fc7 diff --git a/docs/submodules/cli.git b/docs/submodules/cli.git -Subproject e2f4d5f0c49b9135aceb4b3e59cc1434bb6699a +Subproject f7c6592e38c554960a5673354db38131607b294 diff --git a/docs/submodules/dcaegen2.git b/docs/submodules/dcaegen2.git -Subproject 768421bae7586ffe6c4dc2f967471a2c5434cd9 +Subproject eaac78d809a0a019718cb8b070f496b6883bb13 diff --git a/docs/submodules/dmaap/dbcapi.git b/docs/submodules/dmaap/dbcapi.git -Subproject 955500a4aa5c86a1ccc8c4bdf81c65daff41070 +Subproject 8f54f37825746cf82b33a21ff356950eb682d29 diff --git a/docs/submodules/dmaap/messagerouter/messageservice.git b/docs/submodules/dmaap/messagerouter/messageservice.git -Subproject e745fdfeb9927114510ce655aeeb4309b4b403b +Subproject 36fa6819b95aa6797263b1fedc905eb0e768119 diff --git a/docs/submodules/holmes/rule-management.git b/docs/submodules/holmes/rule-management.git -Subproject 2bc21cc9a4f0e7810449b692587608af1762932 +Subproject 56c8610f708a4f6a20cb86428a88d917289fb65 diff --git a/docs/submodules/integration.git b/docs/submodules/integration.git -Subproject ca86676cacecfec5a63f888011737531b7da403 +Subproject 7657b0e2cb4a8b1833b10bc6c91297981d376a5 diff --git a/docs/submodules/logging-analytics.git b/docs/submodules/logging-analytics.git -Subproject 3456da7da32c08520a22771b8452e9a36691bcb +Subproject 9aaa8f39949d7dc3d66888797951a20a7bced14 diff --git a/docs/submodules/modeling/toscaparsers.git b/docs/submodules/modeling/toscaparsers.git -Subproject dfed90c2ddabcbbc016a5431acc446dc55b1c02 +Subproject 1ca11342468ac121e6468ecf5ece5bdfa329eec diff --git a/docs/submodules/msb/apigateway.git b/docs/submodules/msb/apigateway.git -Subproject ff2778b42597fecdf8ebcf1a721320b43094a1e +Subproject 21253185c17ef038e71146112fc948b7c9ad572 diff --git a/docs/submodules/multicloud/framework.git b/docs/submodules/multicloud/framework.git -Subproject a47bd5937ca0a7dd88533c05cbf8e67010ab56f +Subproject 87e46652b3f319d0b63df22e6782775d5c6ce3d diff --git a/docs/submodules/music.git b/docs/submodules/music.git -Subproject 932c9e80911645798712a77e4cee9230a4b5940 +Subproject 5e5d6ed9badebfbc1cc65a90e3de8dad232f9e4 diff --git a/docs/submodules/oom.git b/docs/submodules/oom.git -Subproject 83676f16c66a16e16f4789e0b65804a3705ca08 +Subproject 060359c287c7a328804a9a6012cbbede3219562 diff --git a/docs/submodules/optf/has.git b/docs/submodules/optf/has.git -Subproject e1f901c6ffe0a4a1ec16ba675576084f554523c +Subproject a783f589b9cc06e10f6eed93ede754353eb6e72 diff --git a/docs/submodules/optf/osdf.git b/docs/submodules/optf/osdf.git -Subproject 9a7f7627126af0db557517d0c02b01e37d75741 +Subproject 9fe615529a9fb71d347a5ef6fd88768a45bfa68 diff --git a/docs/submodules/policy/engine.git b/docs/submodules/policy/engine.git -Subproject a8f71f9093ad57afe14582803af8a3761ff270e +Subproject 141052c6dcabdddf20f2b46d95540f1ceb0d729 diff --git a/docs/submodules/portal.git b/docs/submodules/portal.git -Subproject c2178ff5ff354811ba01666e15ad06166df5e54 +Subproject 7235549c9a028b494cb21f3ed9c1087dd07f003 diff --git a/docs/submodules/sdc.git b/docs/submodules/sdc.git -Subproject 1add92e5da0367c8fb2f19378ca34f097b87016 +Subproject ec3b877ab6d9ed87bdecfe420fcfe0436b3cfe7 diff --git a/docs/submodules/sdc/sdc-docker-base.git b/docs/submodules/sdc/sdc-docker-base.git -Subproject 4bcf436c7f2e955a2dffb7d4293f10ea15c38d6 +Subproject 28fc3deb05c170d4b4e08e5431bd37c29f3d64a diff --git a/docs/submodules/sdc/sdc-workflow-designer.git b/docs/submodules/sdc/sdc-workflow-designer.git -Subproject f0249c9508dc710e94c8558d7487fdeb99ef28a +Subproject 61c926695f5bd5977dc10a77010b0500a16bb6a diff --git a/docs/submodules/sdnc/oam.git b/docs/submodules/sdnc/oam.git -Subproject 66b7d18ae11ea4975977b28333086f25d46d578 +Subproject 110b9d3f108e8f81f705ec4eeb2102f98f220d3 diff --git a/docs/submodules/so.git b/docs/submodules/so.git -Subproject cd5a3ea9724a98bcc388a805be1fe384407edc6 +Subproject 35c09da5fd1d9c1a128560b2b2e45ff58a06276 diff --git a/docs/submodules/usecase-ui.git b/docs/submodules/usecase-ui.git -Subproject b8647fbfbcf234848047d7ab1e63d186840b537 +Subproject 68241b80d1a43198027a0beb71974455ee9723f diff --git a/docs/submodules/vfc/nfvo/lcm.git b/docs/submodules/vfc/nfvo/lcm.git -Subproject 95095eec073d0aae71b2b353da0d4ba7d3fe906 +Subproject fa5ce71293ba07ee8f0978fa81ab97c6bf26dfc diff --git a/docs/submodules/vid.git b/docs/submodules/vid.git -Subproject 195a4993601a572df71b7905b6720eeda1a6ec2 +Subproject ef8a6b47847012fd59ea20da21d8d3d7c4a301e diff --git a/docs/submodules/vnfrqts/requirements.git b/docs/submodules/vnfrqts/requirements.git -Subproject 64f81faf1419edd20a9224ff5a695d5cc7ae1f9 +Subproject 8274f893dd8e46a320a3a2b7a5c44430a8d4e76 diff --git a/docs/submodules/vnfrqts/testcases.git b/docs/submodules/vnfrqts/testcases.git -Subproject 3058c86174c1e3722ca0550d92702f4c0e10fd2 +Subproject cdc4c8d541d2962868cd146084c79bd02482a6d diff --git a/docs/submodules/vnfsdk/model.git b/docs/submodules/vnfsdk/model.git -Subproject d0bf33a9d909cfe26e80535fc0451a50b073301 +Subproject 6450ae4b530c595f31e2c72231b0db7b4590a3d diff --git a/docs/submodules/vvp/documentation.git b/docs/submodules/vvp/documentation.git -Subproject 94f211815cf59526f06f1839676d6a213557d24 +Subproject 6dee9df5bf854047df8b1c0944dad13f77d0c9e |