diff options
Diffstat (limited to 'docs/release/userguide')
-rw-r--r-- | docs/release/userguide/UC01-feature.userguide.rst | 14 | ||||
-rw-r--r-- | docs/release/userguide/UC02-feature.userguide.rst | 58 | ||||
-rw-r--r-- | docs/release/userguide/UC03-feature.userguide.rst | 29 | ||||
-rw-r--r-- | docs/release/userguide/index.rst | 6 |
4 files changed, 42 insertions, 65 deletions
diff --git a/docs/release/userguide/UC01-feature.userguide.rst b/docs/release/userguide/UC01-feature.userguide.rst index fd3a05f..5cf38e1 100644 --- a/docs/release/userguide/UC01-feature.userguide.rst +++ b/docs/release/userguide/UC01-feature.userguide.rst @@ -1,11 +1,7 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 .. SPDX-License-Identifier CC-BY-4.0 -.. (c) optionally add copywriters name - -.. contents:: - :depth: 3 - :local: +.. (c) Open Platform for NFV Project, Inc. and its contributors ====================================== @@ -21,17 +17,15 @@ Description This use case aims at showcasing the benefits of using ONAP for autonomous Edge Cloud management. -A high level of automation of VNF lifecycle event handling after launch is enabled by ONAP policies -and closed-loop controls, which take care of most lifecycle events (start, stop, scale up/down/in/out, -recovery/migration for HA) as well as their monitoring and SLA management. +A high level of automation of VNF lifecycle event handling after launch is enabled by ONAP policies and closed-loop controls, which take care of most lifecycle events (start, stop, scale up/down/in/out, recovery/migration for HA) as well as their monitoring and SLA management. -Multiple types of VNFs, for different execution environments, are first approved in the catalog thanks -to the onboarding process, and then can be deployed and handled by multiple controllers in a systematic way. +Multiple types of VNFs, for different execution environments, are first approved in the catalog thanks to the onboarding process, and then can be deployed and handled by multiple controllers in a systematic way. This results in management efficiency (lower control/automation overhead) and high degree of autonomy. Preconditions: + #. hardware environment in which Edge cloud may be deployed #. an Edge cloud has been deployed and is ready for operation #. ONAP has been deployed onto a Cloud, and is interfaced (i.e. provisioned for API access) to the Edge cloud diff --git a/docs/release/userguide/UC02-feature.userguide.rst b/docs/release/userguide/UC02-feature.userguide.rst index d5b9481..0ecb7de 100644 --- a/docs/release/userguide/UC02-feature.userguide.rst +++ b/docs/release/userguide/UC02-feature.userguide.rst @@ -1,31 +1,26 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 .. SPDX-License-Identifier CC-BY-4.0 -.. (c) optionally add copywriters name - -.. contents:: - :depth: 3 - :local: +.. (c) Open Platform for NFV Project, Inc. and its contributors ================================================================ Auto User Guide: Use Case 2 Resiliency Improvements Through ONAP ================================================================ -This document provides the user guide for Fraser release of Auto, -specifically for Use Case 2: Resiliency Improvements Through ONAP. +This document provides the user guide for Fraser release of Auto, specifically for Use Case 2: Resiliency Improvements Through ONAP. Description =========== -This use case illustrates VNF failure recovery time reduction with ONAP, thanks to its automated monitoring and management. -It simulates an underlying problem (failure, stress, etc.: any adverse condition in the network that can impact VNFs), -tracks a VNF, and measures the amount of time it takes for ONAP to restore the VNF functionality. +This use case illustrates VNF failure recovery time reduction with ONAP, thanks to its automated monitoring and management. It: + +* simulates an underlying problem (failure, stress, or any adverse condition in the network that can impact VNFs) +* tracks a VNF +* measures the amount of time it takes for ONAP to restore the VNF functionality. -The benefit for NFV edge service providers is to assess what degree of added VIM+NFVI platform resilience for VNFs is obtained by -leveraging ONAP closed-loop control, vs. VIM+NFVI self-managed resilience (which may not be aware of the VNF or the corresponding -end-to-end Service, but only of underlying resources such as VMs and servers). +The benefit for NFV edge service providers is to assess what degree of added VIM+NFVI platform resilience for VNFs is obtained by leveraging ONAP closed-loop control, vs. VIM+NFVI self-managed resilience (which may not be aware of the VNF or the corresponding end-to-end Service, but only of underlying resources such as VMs and servers). Preconditions: @@ -35,12 +30,9 @@ Preconditions: #. ONAP has been deployed onto a cloud and is interfaced (i.e. provisioned for API access) to the Edge cloud #. Components of ONAP have been deployed on the Edge cloud as necessary for specific test objectives -In future releases, Auto Use cases will also include the deployment of ONAP (if not already installed), the deployment -of test VNFs (pre-existing VNFs in pre-existing ONAP can be used in the test as well), the configuration of ONAP for -monitoring these VNFs (policies, CLAMP, DCAE), in addition to the test scripts which simulate a problem and measures recovery time. +In future releases, Auto Use cases will also include the deployment of ONAP (if not already installed), the deployment of test VNFs (pre-existing VNFs in pre-existing ONAP can be used in the test as well), the configuration of ONAP for monitoring these VNFs (policies, CLAMP, DCAE), in addition to the test scripts which simulate a problem and measures recovery time. -Different types of problems can be simulated, hence the identification of multiple test cases corresponding to this use case, -as illustrated in this diagram: +Different types of problems can be simulated, hence the identification of multiple test cases corresponding to this use case, as illustrated in this diagram: .. image:: auto-UC02-testcases.jpg @@ -74,20 +66,19 @@ Test execution high-level description The following two MSCs (Message Sequence Charts) show the actors and high-level interactions. -The first MSC shows the preparation activities (assuming the hardware, network, cloud, and ONAP have already been installed): -onboarding and deployment of VNFs (via ONAP portal and modules in sequence: SDC, VID, SO), and ONAP configuration -(policy framework, closed-loops in CLAMP, activation of DCAE). +The first MSC shows the preparation activities (assuming the hardware, network, cloud, and ONAP have already been installed): onboarding and deployment of VNFs (via ONAP portal and modules in sequence: SDC, VID, SO), and ONAP configuration (policy framework, closed-loops in CLAMP, activation of DCAE). .. image:: auto-UC02-preparation.jpg + The second MSC illustrates the pattern of all test cases for the Resiliency Improvements: + * simulate the chosen problem (a.k.a. a "Challenge") for this test case, for example suspend a VM which may be used by a VNF * start tracking the target VNF of this test case * measure the ONAP-orchestrated VNF Recovery Time * then the test stops simulating the problem (for example: resume the VM that was suspended), -In parallel, the MSC also shows the sequence of events happening in ONAP, thanks to its configuration to provide Service -Assurance for the VNF. +In parallel, the MSC also shows the sequence of events happening in ONAP, thanks to its configuration to provide Service Assurance for the VNF. .. image:: auto-UC02-pattern.jpg @@ -95,42 +86,47 @@ Assurance for the VNF. Test design: data model, implementation modules =============================================== -The high-level design of classes shows the identification of several entities: +The high-level design of classes identifies several entities: + * Test Case: as identified above, each is a special case of the overall use case (e.g., categorized by challenge type) * Test Definition: gathers all the information necessary to run a certain test case * Metric Definition: describes a certain metric that may be measured, in addition to Recovery Time * Challenge Definition: describe the challenge (problem, failure, stress, ...) simulated by the test case -* Recipient: entity that can receive commands and send responses, and that is queried by the Test Definition or Challenge Definition -(a recipient would be typically a management service, with interfaces (CLI or API) for clients to query) +* Recipient: entity that can receive commands and send responses, and that is queried by the Test Definition or Challenge Definition (a recipient would be typically a management service, with interfaces (CLI or API) for clients to query) * Resources: with 3 types (VNF, cloud virtual resource such as a VM, physical resource such as a server) + Three of these entities have execution-time corresponding classes: + * Test Execution, which captures all the relevant data of the execution of a Test Definition * Challenge Execution, which captures all the relevant data of the execution of a Challenge Definition * Metric Value, which captures the a quantitative measurement of a Metric Definition (with a timestamp) .. image:: auto-UC02-data1.jpg + The following diagram illustrates an implementation-independent design of the attributes of these entities: + .. image:: auto-UC02-data2.jpg + This next diagram shows the Python classes and attributes, as implemented by this Use Case (for all test cases): .. image:: auto-UC02-data3.jpg -Test definition data is stored in serialization files (Python pickles), while test execution data is stored in CSV -files, for easier post-analysis. -The module design is straightforward: functions and classes for managing data, for interfacing with recipients, -for executing tests, and for interacting with the test user (choosing a Test Definition, showing the details -of a Test Definition, starting the execution). +Test definition data is stored in serialization files (Python pickles), while test execution data is stored in CSV files, for easier post-analysis. + +The module design is straightforward: functions and classes for managing data, for interfacing with recipients, for executing tests, and for interacting with the test user (choosing a Test Definition, showing the details of a Test Definition, starting the execution). .. image:: auto-UC02-module1.jpg + This last diagram shows the test user menu functions: .. image:: auto-UC02-module2.jpg + In future releases of Auto, testing environments such as FuncTest and Yardstick might be leveraged. Also, anonymized test results could be collected from users willing to share them, and aggregates could be diff --git a/docs/release/userguide/UC03-feature.userguide.rst b/docs/release/userguide/UC03-feature.userguide.rst index 246b2c5..5f28158 100644 --- a/docs/release/userguide/UC03-feature.userguide.rst +++ b/docs/release/userguide/UC03-feature.userguide.rst @@ -1,11 +1,7 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 .. SPDX-License-Identifier CC-BY-4.0 -.. (c) optionally add copywriters name - -.. contents:: - :depth: 3 - :local: +.. (c) Open Platform for NFV Project, Inc. and its contributors =========================================== @@ -21,27 +17,17 @@ Description This Use Case shows how ONAP can help ensuring that virtual CPEs (including vFW: virtual firewalls) in Edge Cloud are enterprise-grade. -ONAP operations include a verification process for VNF onboarding (i.e. inclusion in the ONAP catalog), -with multiple Roles (designer, tester, governor, operator), responsible for approving proposed VNFs -(as VSPs (Vendor Software Products), and eventually as end-to-end Services). +ONAP operations include a verification process for VNF onboarding (i.e. inclusion in the ONAP catalog), with multiple Roles (designer, tester, governor, operator), responsible for approving proposed VNFs (as VSPs (Vendor Software Products), and eventually as end-to-end Services). -This process guarantees a minimum level of quality of onboarded VNFs. If all deployed vCPEs are only -chosen from such an approved ONAP catalog, the resulting deployed end-to-end vCPE services will meet -enterprise-grade requirements. ONAP provides a NBI in addition to a standard portal, thus enabling -a programmatic deployment of VNFs, still conforming to ONAP processes. +This process guarantees a minimum level of quality of onboarded VNFs. If all deployed vCPEs are only chosen from such an approved ONAP catalog, the resulting deployed end-to-end vCPE services will meet enterprise-grade requirements. ONAP provides a NBI in addition to a standard portal, thus enabling a programmatic deployment of VNFs, still conforming to ONAP processes. -Moreover, ONAP also comprises real-time monitoring (by the DCAE component), which monitors performance for SLAs, -can adjust allocated resources accordingly (elastic adjustment at VNF level), and can ensure High Availability. +Moreover, ONAP also comprises real-time monitoring (by the DCAE component), which monitors performance for SLAs, can adjust allocated resources accordingly (elastic adjustment at VNF level), and can ensure High Availability. -DCAE executes directives coming from policies described in the Policy Framework, and closed-loop controls -described in the CLAMP component. +DCAE executes directives coming from policies described in the Policy Framework, and closed-loop controls described in the CLAMP component. -Finally, this automated approach also reduces costs, since repetitive actions are designed once and executed multiple times, -as vCPEs are instantiated and decommissioned (frequent events, given the variability of business activity, -and a Small Business market similar to the Residential market: many contract updates resulting in many vCPE changes). +Finally, this automated approach also reduces costs, since repetitive actions are designed once and executed multiple times, as vCPEs are instantiated and decommissioned (frequent events, given the variability of business activity, and a Small Business market similar to the Residential market: many contract updates resulting in many vCPE changes). -NFV edge service providers need to provide site2site, site2dc (Data Center) and site2internet services to tenants -both efficiently and safely, by deploying such qualified enterprise-grade vCPE. +NFV edge service providers need to provide site2site, site2dc (Data Center) and site2internet services to tenants both efficiently and safely, by deploying such qualified enterprise-grade vCPE. Preconditions: @@ -76,6 +62,7 @@ Details on the test cases corresponding to this use case: * Spin up a vFW instance: Spin up a vFW instance, by calling NBI of the orchestrator. * VPN as a Service + * Subscribe to a VPN service: Subscribe to a VPN service, by calling NBI of the orchestrator. * Unsubscribe to a VPN service: Unsubscribe to a VPN service, by calling NBI of the orchestrator. diff --git a/docs/release/userguide/index.rst b/docs/release/userguide/index.rst index ba44e0b..7cfbe94 100644 --- a/docs/release/userguide/index.rst +++ b/docs/release/userguide/index.rst @@ -2,8 +2,7 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 -.. (c) <optionally add copywriters name> - +.. (c) Open Platform for NFV Project, Inc. and its contributors ============================================ OPNFV Auto (ONAP-Automated OPNFV) User Guide @@ -16,7 +15,8 @@ OPNFV Auto (ONAP-Automated OPNFV) User Guide .. by the installer project. .. toctree:: - :maxdepth: 1 + :numbered: + :maxdepth: 2 UC01-feature.userguide.rst UC02-feature.userguide.rst |