diff options
Diffstat (limited to 'docs')
23 files changed, 1538 insertions, 0 deletions
diff --git a/docs/release/installation/UC01-feature.userguide.rst b/docs/release/installation/UC01-feature.userguide.rst new file mode 100644 index 0000000..5da0865 --- /dev/null +++ b/docs/release/installation/UC01-feature.userguide.rst @@ -0,0 +1,84 @@ +.. 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 + + +================================================================ +Auto User Guide: Use Case 1 Edge Cloud +================================================================ + +This document provides the user guide for Fraser release of Auto, +specifically for Use Case 1: Edge Cloud. + +.. contents:: + :depth: 3 + :local: + + +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. + +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 + + + +Main Success Scenarios: + +* lifecycle management - stop, stop, scale (dependent upon telemetry) + +* recovering from faults (detect, determine appropriate response, act); i.e. exercise closed-loop policy engine in ONAP + + * verify mechanics of control plane interaction + +* collection of telemetry for machine learning + + +Details on the test cases corresponding to this use case: + +* Environment check + + * Basic environment check: Create test script to check basic VIM (OpenStack), ONAP, and VNF are up and running + +* VNF lifecycle management + + * VNF Instance Management: Validation of VNF Instance Management which includes VNF instantiation, VNF State Management and termination + + * Tacker Monitoring Driver (VNFMonitorPing): + + * Write Tacker Monitor driver to handle monitor_call and based on return state value create custom events + * If Ping to VNF fails, trigger below events + + * Event 1 : Collect failure logs from VNF + * Event 2 : Soft restart/respawn the VNF + + * Integrate with Telemetry + + * Create TOSCA template policies to implement ceilometer data collection service + * Collect CPU utilization data, compare with threshold, and perform action accordingly (respawn, scale-in/scale-out) + + + +Test execution high-level description +===================================== + +<TBC> + + + + diff --git a/docs/release/installation/UC01-installation.instruction.rst b/docs/release/installation/UC01-installation.instruction.rst new file mode 100644 index 0000000..9ecb8bd --- /dev/null +++ b/docs/release/installation/UC01-installation.instruction.rst @@ -0,0 +1,212 @@ +.. 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
+
+========
+Abstract
+========
+
+This document describes how to install OPNFV Auto Use Case 1: Edge Cloud, its dependencies and required system resources.
+
+.. contents::
+ :depth: 3
+ :local:
+
+Version history
+---------------------
+
++--------------------+--------------------+--------------------+--------------------+
+| **Date** | **Ver.** | **Author** | **Comment** |
+| | | | |
++--------------------+--------------------+--------------------+--------------------+
+| 2015-04-14 | 0.1.0 | Jonas Bjurel | First draft |
+| | | | |
++--------------------+--------------------+--------------------+--------------------+
+| | 0.1.1 | | |
+| | | | |
++--------------------+--------------------+--------------------+--------------------+
+| | 1.0 | | |
+| | | | |
+| | | | |
++--------------------+--------------------+--------------------+--------------------+
+
+
+Introduction
+============
+<INTRODUCTION TO THE SCOPE AND INTENTION OF THIS DOCUMENT AS WELL AS TO THE SYSTEM TO BE INSTALLED>
+
+<EXAMPLE>:
+
+This document describes the supported software and hardware configurations for the
+Fuel OPNFV reference platform as well as providing guidelines on how to install and
+configure such reference system.
+
+Although the available installation options gives a high degree of freedom in how the system is set-up,
+with what architecture, services and features, etc., not nearly all of those permutations provides
+a OPNFV compliant reference architecture. Following the guidelines in this document ensures
+a result that is OPNFV compliant.
+
+The audience of this document is assumed to have good knowledge in network and Unix/Linux administration.
+
+
+Preface
+=======
+<DESCRIBE NEEDED PREREQUISITES, PLANNING, ETC.>
+
+<EXAMPLE>:
+
+Before starting the installation of Fuel@OPNFV, some planning must preceed.
+
+First of all, the Fuel@OPNFV .iso image needs to be retrieved,
+the Latest stable Arno release of Fuel@OPNFV can be found here: <www.opnfv.org/abc/def>
+
+Alternatively, you may build the .iso from source by cloning the opnfv/genesis git repository:
+<git clone https://<linux foundation uid>@gerrit.opnf.org/gerrit/genesis>
+Check-out the Arno release:
+<cd genesis; git checkout arno>
+Goto the fuel directory and build the .iso
+<cd fuel/build; make all>
+
+Familiarize yourself with the Fuel 6.0.1 version by reading the following documents:
+- abc <http://wiki.openstack.org/abc>
+- def <http://wiki.openstack.org/def>
+- ghi <http://wiki.openstack.org/ghi>
+
+Secondly, a number of deployment specific parameters must be collected, those are:
+
+1. Provider sub-net and gateway information
+
+2. Provider VLAN information
+
+3. Provider DNS addresses
+
+4. Provider NTP addresses
+
+This information will be needed for the configuration procedures provided in this document.
+
+
+Hardware requirements
+=====================
+<PROVIDE A LIST OF MINIMUM HARDWARE REQUIREMENTS NEEDED FOR THE INSTALL>
+
+<EXAMPLE>:
+
+Following minimum hardware requirements must be met for installation of Fuel@OPNFV:
+
++--------------------+----------------------------------------------------+
+| **HW Aspect** | **Requirement** |
+| | |
++--------------------+----------------------------------------------------+
+| **# of servers** | Minimum 5 (3 for non redundant deployment) |
+| | 1 Fuel deployment master (may be virtualized) |
+| | 3(1) Controllers |
+| | 1 Compute |
++--------------------+----------------------------------------------------+
+| **CPU** | Minimum 1 socket x86_AMD64 Ivy bridge 1.6 GHz |
+| | |
++--------------------+----------------------------------------------------+
+| **RAM** | Minimum 16GB/server (Depending on VNF work load) |
+| | |
++--------------------+----------------------------------------------------+
+| **Disk** | Minimum 256GB 10kRPM spinning disks |
+| | |
++--------------------+----------------------------------------------------+
+| **NICs** | 2(1)x10GE Niantec for Private/Public (Redundant) |
+| | |
+| | 2(1)x10GE Niantec for SAN (Redundant) |
+| | |
+| | 2(1)x1GE for admin (PXE) and control (RabitMQ,etc) |
+| | |
++--------------------+----------------------------------------------------+
+
+
+Top of the rack (TOR) Configuration requirements
+================================================
+<DESCRIBE NEEDED NETWORK TOPOLOGY SETUP IN THE TORs>
+
+<EXAMPLE>:
+
+The switching infrastructure provides connectivity for the OPNFV infra-structure operations as well as
+for the tenant networks (East/West) and provider connectivity (North/South bound connectivity).
+The switching connectivity can (but does not need to) be fully redundant,
+in case it and comprises a redundant 10GE switch pair for "Traffic/Payload/SAN" purposes as well as
+a 1GE switch pair for "infrastructure control-, management and administration"
+
+The switches are **not** automatically configured from the OPNFV reference platform.
+All the networks involved in the OPNFV infra-structure as well as the provider networks
+and the private tenant VLANs needs to be manually configured.
+
+This following sections guides through required black-box switch configurations.
+
+VLAN considerations and blue-print
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+IP Address plan considerations and blue-print
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+
+OPNFV Software installation and deployment
+==========================================
+<DESCRIBE THE FULL PROCEDURES FOR THE INSTALLATION OF THE OPNFV COMPONENT INSTALLATION AND DEPLOYMENT>
+
+<EXAMPLE>:
+
+This section describes the installation of the Fuel@OPNFV installation server (Fuel master)
+as well as the deployment of the full OPNFV reference platform stack across a server cluster.
+Etc.
+
+Install Fuel master
+^^^^^^^^^^^^^^^^^^^^^
+
+Create an OPNV (Fuel Environment)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Configure the OPNFV environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Deploy the OPNFV environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+
+Installation health-check
+=========================
+<DESCRIBE ANY MEANS TO DO VERIFY THE INTEGRITY AND HEALTHYNESS OF THE INSTALL>
+
+<EXAMPLE>:
+
+Now that the OPNFV environment has been created, and before the post installation configurations is started,
+perform a system health check from the Fuel GUI:
+
+- Select the "Health check" TAB.
+- Select all test-cases
+- And click "Run tests"
+
+All test cases except the following should pass:
+
+Post installation and deployment actions
+------------------------------------------
+<DESCRIBE ANY POST INSTALLATION ACTIONS/CONFIGURATIONS NEEDED>
+
+<EXAMPLE>:
+After the OPNFV deployment is completed, the following manual changes needs to be performed in order
+for the system to work according OPNFV standards.
+
+**Change host OS password:**
+Change the Host OS password by......
+
+
+References
+==========
+<PROVIDE NEEDED/USEFUL REFERENCES>
+
+<EXAMPLES>:
+
+OPNFV
+^^^^^^^^^^
+
+OpenStack
+^^^^^^^^^^^
+
+OpenDaylight
+^^^^^^^^^^^^^^^
diff --git a/docs/release/installation/UC02-feature.userguide.rst b/docs/release/installation/UC02-feature.userguide.rst new file mode 100644 index 0000000..32a6df8 --- /dev/null +++ b/docs/release/installation/UC02-feature.userguide.rst @@ -0,0 +1,145 @@ +.. 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 + + +================================================================ +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. + +.. contents:: + :depth: 3 + :local: + + +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. + +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: + +#. hardware environment in which Edge cloud may be deployed +#. 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 +#. 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. + +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 + +Description of simulated problems/challenges: + +* Physical Infra Failure + + * Migration upon host failure: Compute host power is interrupted, and affected workloads are migrated to other available hosts. + * Migration upon disk failure: Disk volumes are unmounted, and affected workloads are migrated to other available hosts. + * Migration upon link failure: Traffic on links is interrupted/corrupted, and affected workloads are migrated to other available hosts. + * Migration upon NIC failure: NIC ports are disabled by host commands, and affected workloads are migrated to other available hosts. + +* Virtual Infra Failure + + * OpenStack compute host service fail: Core OpenStack service processes on compute hosts are terminated, and auto-restored, or affected workloads are migrated to other available hosts. + * SDNC service fail: Core SDNC service processes are terminated, and auto-restored. + * OVS fail: OVS bridges are disabled, and affected workloads are migrated to other available hosts. + * etc. + +* Security + + * Host tampering: Host tampering is detected, the host is fenced, and affected workloads are migrated to other available hosts. + * Host intrusion: Host intrusion attempts are detected, an offending workload, device, or flow is identified and fenced, and as needed affected workloads are migrated to other available hosts. + * Network intrusion: Network intrusion attempts are detected, and an offending flow is identified and fenced. + + + + +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). + +.. 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. + +.. image:: auto-UC02-pattern.jpg + + +Test design: data model, implementation modules +=============================================== + +The high-level design of classes shows the identification of 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) +* 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). + +.. 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 +maintained as benchmarks. + + + + + + + + diff --git a/docs/release/installation/UC02-installation.instruction.rst b/docs/release/installation/UC02-installation.instruction.rst new file mode 100644 index 0000000..0e126dd --- /dev/null +++ b/docs/release/installation/UC02-installation.instruction.rst @@ -0,0 +1,195 @@ +.. 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
+
+========
+Abstract
+========
+
+This document describes how to install OPNFV Auto Use Case 2: Resiliency Improvements Through ONAP, its dependencies and required system resources.
+
+.. contents::
+ :depth: 3
+ :local:
+
+
+
+Introduction
+============
+<INTRODUCTION TO THE SCOPE AND INTENTION OF THIS DOCUMENT AS WELL AS TO THE SYSTEM TO BE INSTALLED>
+
+<EXAMPLE>:
+
+This document describes the supported software and hardware configurations for the
+Fuel OPNFV reference platform as well as providing guidelines on how to install and
+configure such reference system.
+
+Although the available installation options gives a high degree of freedom in how the system is set-up,
+with what architecture, services and features, etc., not nearly all of those permutations provides
+a OPNFV compliant reference architecture. Following the guidelines in this document ensures
+a result that is OPNFV compliant.
+
+The audience of this document is assumed to have good knowledge in network and Unix/Linux administration.
+
+
+Preface
+=======
+<DESCRIBE NEEDED PREREQUISITES, PLANNING, ETC.>
+
+<EXAMPLE>:
+
+Before starting the installation of Fuel@OPNFV, some planning must preceed.
+
+First of all, the Fuel@OPNFV .iso image needs to be retrieved,
+the Latest stable Arno release of Fuel@OPNFV can be found here: <www.opnfv.org/abc/def>
+
+Alternatively, you may build the .iso from source by cloning the opnfv/genesis git repository:
+<git clone https://<linux foundation uid>@gerrit.opnf.org/gerrit/genesis>
+Check-out the Arno release:
+<cd genesis; git checkout arno>
+Goto the fuel directory and build the .iso
+<cd fuel/build; make all>
+
+Familiarize yourself with the Fuel 6.0.1 version by reading the following documents:
+- abc <http://wiki.openstack.org/abc>
+- def <http://wiki.openstack.org/def>
+- ghi <http://wiki.openstack.org/ghi>
+
+Secondly, a number of deployment specific parameters must be collected, those are:
+
+1. Provider sub-net and gateway information
+
+2. Provider VLAN information
+
+3. Provider DNS addresses
+
+4. Provider NTP addresses
+
+This information will be needed for the configuration procedures provided in this document.
+
+
+Hardware requirements
+=====================
+<PROVIDE A LIST OF MINIMUM HARDWARE REQUIREMENTS NEEDED FOR THE INSTALL>
+
+<EXAMPLE>:
+
+Following minimum hardware requirements must be met for installation of Fuel@OPNFV:
+
++--------------------+----------------------------------------------------+
+| **HW Aspect** | **Requirement** |
+| | |
++--------------------+----------------------------------------------------+
+| **# of servers** | Minimum 5 (3 for non redundant deployment) |
+| | 1 Fuel deployment master (may be virtualized) |
+| | 3(1) Controllers |
+| | 1 Compute |
++--------------------+----------------------------------------------------+
+| **CPU** | Minimum 1 socket x86_AMD64 Ivy bridge 1.6 GHz |
+| | |
++--------------------+----------------------------------------------------+
+| **RAM** | Minimum 16GB/server (Depending on VNF work load) |
+| | |
++--------------------+----------------------------------------------------+
+| **Disk** | Minimum 256GB 10kRPM spinning disks |
+| | |
++--------------------+----------------------------------------------------+
+| **NICs** | 2(1)x10GE Niantec for Private/Public (Redundant) |
+| | |
+| | 2(1)x10GE Niantec for SAN (Redundant) |
+| | |
+| | 2(1)x1GE for admin (PXE) and control (RabitMQ,etc) |
+| | |
++--------------------+----------------------------------------------------+
+
+
+Top of the rack (TOR) Configuration requirements
+================================================
+<DESCRIBE NEEDED NETWORK TOPOLOGY SETUP IN THE TORs>
+
+<EXAMPLE>:
+
+The switching infrastructure provides connectivity for the OPNFV infra-structure operations as well as
+for the tenant networks (East/West) and provider connectivity (North/South bound connectivity).
+The switching connectivity can (but does not need to) be fully redundant,
+in case it and comprises a redundant 10GE switch pair for "Traffic/Payload/SAN" purposes as well as
+a 1GE switch pair for "infrastructure control-, management and administration"
+
+The switches are **not** automatically configured from the OPNFV reference platform.
+All the networks involved in the OPNFV infra-structure as well as the provider networks
+and the private tenant VLANs needs to be manually configured.
+
+This following sections guides through required black-box switch configurations.
+
+VLAN considerations and blue-print
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+IP Address plan considerations and blue-print
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+
+OPNFV Software installation and deployment
+==========================================
+<DESCRIBE THE FULL PROCEDURES FOR THE INSTALLATION OF THE OPNFV COMPONENT INSTALLATION AND DEPLOYMENT>
+
+<EXAMPLE>:
+
+This section describes the installation of the Fuel@OPNFV installation server (Fuel master)
+as well as the deployment of the full OPNFV reference platform stack across a server cluster.
+Etc.
+
+Install Fuel master
+^^^^^^^^^^^^^^^^^^^^^
+
+Create an OPNV (Fuel Environment)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Configure the OPNFV environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Deploy the OPNFV environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+
+Installation health-check
+=========================
+<DESCRIBE ANY MEANS TO DO VERIFY THE INTEGRITY AND HEALTHYNESS OF THE INSTALL>
+
+<EXAMPLE>:
+
+Now that the OPNFV environment has been created, and before the post installation configurations is started,
+perform a system health check from the Fuel GUI:
+
+- Select the "Health check" TAB.
+- Select all test-cases
+- And click "Run tests"
+
+All test cases except the following should pass:
+
+Post installation and deployment actions
+------------------------------------------
+<DESCRIBE ANY POST INSTALLATION ACTIONS/CONFIGURATIONS NEEDED>
+
+<EXAMPLE>:
+After the OPNFV deployment is completed, the following manual changes needs to be performed in order
+for the system to work according OPNFV standards.
+
+**Change host OS password:**
+Change the Host OS password by......
+
+
+References
+==========
+<PROVIDE NEEDED/USEFUL REFERENCES>
+
+<EXAMPLES>:
+
+OPNFV
+^^^^^^^^^^
+
+OpenStack
+^^^^^^^^^^^
+
+OpenDaylight
+^^^^^^^^^^^^^^^
diff --git a/docs/release/installation/UC03-feature.userguide.rst b/docs/release/installation/UC03-feature.userguide.rst new file mode 100644 index 0000000..354d052 --- /dev/null +++ b/docs/release/installation/UC03-feature.userguide.rst @@ -0,0 +1,100 @@ +.. 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 + + +================================================================ +Auto User Guide: Use Case 3 Enterprise vCPE +================================================================ + +This document provides the user guide for Fraser release of Auto, +specifically for Use Case 3: Enterprise vCPE. + +.. contents:: + :depth: 3 + :local: + + +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). + +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. + +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). + +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: + +#. hardware environment in which Edge cloud may be deployed +#. an Edge cloud has been deployed and is ready for operation +#. enterprise edge devices, such as ThinCPE, have access to the Edge cloud with WAN interfaces +#. ONAP components (MSO, SDN-C, APP-C and VNFM) have been deployed onto a cloud and are interfaced (i.e. provisioned for API access) to the Edge cloud + + +Main Success Scenarios: + +* VNF spin-up + + * vCPE spin-up: MSO calls the VNFM to spin up a vCPE instance from the catalog and then updates the active VNF list + * vFW spin-up: MSO calls the VNFM to spin up a vFW instance from the catalog and then updates the active VNF list + +* site2site + + * L3VPN service subscribing: MSO calls the SDNC to create VXLAN tunnels to carry L2 traffic between client's ThinCPE and SP's vCPE, and enables vCPE to route between different sites. + * L3VPN service unsubscribing: MSO calls the SDNC to destroy tunnels and routes, thus disable traffic between different sites. + + +See `ONAP description of vCPE use case <https://wiki.onap.org/display/DW/Use+Case+proposal%3A+Enterprise+vCPE>`_ for more details, including MSCs. + + +Details on the test cases corresponding to this use case: + +* VNF Management + + * Spin up a vCPE instance: Spin up a vCPE instance, by calling NBI of the orchestrator. + * 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. + +* Internet as a Service + + * Subscribe to an Internet service: Subscribe to an Internet service, by calling NBI of the orchestrator. + * Unsubscribe to an Internet service: Unsubscribe to an Internet service, by calling NBI of the orchestrator. + + +Test execution high-level description +===================================== + +<TBC> + + + + + + + + + diff --git a/docs/release/installation/UC03-installation.instruction.rst b/docs/release/installation/UC03-installation.instruction.rst new file mode 100644 index 0000000..0221885 --- /dev/null +++ b/docs/release/installation/UC03-installation.instruction.rst @@ -0,0 +1,212 @@ +.. 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
+
+========
+Abstract
+========
+
+This document describes how to install OPNFV Auto Use Case 3: Enterprise vCPE, its dependencies and required system resources.
+
+.. contents::
+ :depth: 3
+ :local:
+
+Version history
+---------------------
+
++--------------------+--------------------+--------------------+--------------------+
+| **Date** | **Ver.** | **Author** | **Comment** |
+| | | | |
++--------------------+--------------------+--------------------+--------------------+
+| 2015-04-14 | 0.1.0 | Jonas Bjurel | First draft |
+| | | | |
++--------------------+--------------------+--------------------+--------------------+
+| | 0.1.1 | | |
+| | | | |
++--------------------+--------------------+--------------------+--------------------+
+| | 1.0 | | |
+| | | | |
+| | | | |
++--------------------+--------------------+--------------------+--------------------+
+
+
+Introduction
+============
+<INTRODUCTION TO THE SCOPE AND INTENTION OF THIS DOCUMENT AS WELL AS TO THE SYSTEM TO BE INSTALLED>
+
+<EXAMPLE>:
+
+This document describes the supported software and hardware configurations for the
+Fuel OPNFV reference platform as well as providing guidelines on how to install and
+configure such reference system.
+
+Although the available installation options gives a high degree of freedom in how the system is set-up,
+with what architecture, services and features, etc., not nearly all of those permutations provides
+a OPNFV compliant reference architecture. Following the guidelines in this document ensures
+a result that is OPNFV compliant.
+
+The audience of this document is assumed to have good knowledge in network and Unix/Linux administration.
+
+
+Preface
+=======
+<DESCRIBE NEEDED PREREQUISITES, PLANNING, ETC.>
+
+<EXAMPLE>:
+
+Before starting the installation of Fuel@OPNFV, some planning must preceed.
+
+First of all, the Fuel@OPNFV .iso image needs to be retrieved,
+the Latest stable Arno release of Fuel@OPNFV can be found here: <www.opnfv.org/abc/def>
+
+Alternatively, you may build the .iso from source by cloning the opnfv/genesis git repository:
+<git clone https://<linux foundation uid>@gerrit.opnf.org/gerrit/genesis>
+Check-out the Arno release:
+<cd genesis; git checkout arno>
+Goto the fuel directory and build the .iso
+<cd fuel/build; make all>
+
+Familiarize yourself with the Fuel 6.0.1 version by reading the following documents:
+- abc <http://wiki.openstack.org/abc>
+- def <http://wiki.openstack.org/def>
+- ghi <http://wiki.openstack.org/ghi>
+
+Secondly, a number of deployment specific parameters must be collected, those are:
+
+1. Provider sub-net and gateway information
+
+2. Provider VLAN information
+
+3. Provider DNS addresses
+
+4. Provider NTP addresses
+
+This information will be needed for the configuration procedures provided in this document.
+
+
+Hardware requirements
+=====================
+<PROVIDE A LIST OF MINIMUM HARDWARE REQUIREMENTS NEEDED FOR THE INSTALL>
+
+<EXAMPLE>:
+
+Following minimum hardware requirements must be met for installation of Fuel@OPNFV:
+
++--------------------+----------------------------------------------------+
+| **HW Aspect** | **Requirement** |
+| | |
++--------------------+----------------------------------------------------+
+| **# of servers** | Minimum 5 (3 for non redundant deployment) |
+| | 1 Fuel deployment master (may be virtualized) |
+| | 3(1) Controllers |
+| | 1 Compute |
++--------------------+----------------------------------------------------+
+| **CPU** | Minimum 1 socket x86_AMD64 Ivy bridge 1.6 GHz |
+| | |
++--------------------+----------------------------------------------------+
+| **RAM** | Minimum 16GB/server (Depending on VNF work load) |
+| | |
++--------------------+----------------------------------------------------+
+| **Disk** | Minimum 256GB 10kRPM spinning disks |
+| | |
++--------------------+----------------------------------------------------+
+| **NICs** | 2(1)x10GE Niantec for Private/Public (Redundant) |
+| | |
+| | 2(1)x10GE Niantec for SAN (Redundant) |
+| | |
+| | 2(1)x1GE for admin (PXE) and control (RabitMQ,etc) |
+| | |
++--------------------+----------------------------------------------------+
+
+
+Top of the rack (TOR) Configuration requirements
+================================================
+<DESCRIBE NEEDED NETWORK TOPOLOGY SETUP IN THE TORs>
+
+<EXAMPLE>:
+
+The switching infrastructure provides connectivity for the OPNFV infra-structure operations as well as
+for the tenant networks (East/West) and provider connectivity (North/South bound connectivity).
+The switching connectivity can (but does not need to) be fully redundant,
+in case it and comprises a redundant 10GE switch pair for "Traffic/Payload/SAN" purposes as well as
+a 1GE switch pair for "infrastructure control-, management and administration"
+
+The switches are **not** automatically configured from the OPNFV reference platform.
+All the networks involved in the OPNFV infra-structure as well as the provider networks
+and the private tenant VLANs needs to be manually configured.
+
+This following sections guides through required black-box switch configurations.
+
+VLAN considerations and blue-print
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+IP Address plan considerations and blue-print
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+
+OPNFV Software installation and deployment
+==========================================
+<DESCRIBE THE FULL PROCEDURES FOR THE INSTALLATION OF THE OPNFV COMPONENT INSTALLATION AND DEPLOYMENT>
+
+<EXAMPLE>:
+
+This section describes the installation of the Fuel@OPNFV installation server (Fuel master)
+as well as the deployment of the full OPNFV reference platform stack across a server cluster.
+Etc.
+
+Install Fuel master
+^^^^^^^^^^^^^^^^^^^^^
+
+Create an OPNV (Fuel Environment)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Configure the OPNFV environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Deploy the OPNFV environment
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+
+Installation health-check
+=========================
+<DESCRIBE ANY MEANS TO DO VERIFY THE INTEGRITY AND HEALTHYNESS OF THE INSTALL>
+
+<EXAMPLE>:
+
+Now that the OPNFV environment has been created, and before the post installation configurations is started,
+perform a system health check from the Fuel GUI:
+
+- Select the "Health check" TAB.
+- Select all test-cases
+- And click "Run tests"
+
+All test cases except the following should pass:
+
+Post installation and deployment actions
+------------------------------------------
+<DESCRIBE ANY POST INSTALLATION ACTIONS/CONFIGURATIONS NEEDED>
+
+<EXAMPLE>:
+After the OPNFV deployment is completed, the following manual changes needs to be performed in order
+for the system to work according OPNFV standards.
+
+**Change host OS password:**
+Change the Host OS password by......
+
+
+References
+==========
+<PROVIDE NEEDED/USEFUL REFERENCES>
+
+<EXAMPLES>:
+
+OPNFV
+^^^^^^^^^^
+
+OpenStack
+^^^^^^^^^^^
+
+OpenDaylight
+^^^^^^^^^^^^^^^
diff --git a/docs/release/installation/index.rst b/docs/release/installation/index.rst new file mode 100644 index 0000000..0120e92 --- /dev/null +++ b/docs/release/installation/index.rst @@ -0,0 +1,15 @@ +.. _auto-configguide:
+
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+=====================================================
+OPNFV Auto (ONAP-Automated OPNFV) Configuration Guide
+=====================================================
+
+.. toctree::
+ :maxdepth: 1
+
+ UC01-installation.instruction.rst
+ UC02-installation.instruction.rst
+ UC03-installation.instruction.rst
diff --git a/docs/release/release-notes/Auto-release-notes.rst b/docs/release/release-notes/Auto-release-notes.rst new file mode 100644 index 0000000..84665cd --- /dev/null +++ b/docs/release/release-notes/Auto-release-notes.rst @@ -0,0 +1,245 @@ +.. 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) Open Platform for NFV Project, Inc. and its contributors + + +================== +Auto Release Notes +================== + +This document provides the release notes for Fraser release of Auto. + + +Important notes +=============== + +Initial release (project inception: July 2017). + + +Summary +======= + +OPNFV is a SDNFV system integration project for open-source components, which so far have been mostly limited to the NFVI+VIM as generally described by ETSI. + +In particular, OPNFV has yet to integrate higher-level automation features for VNFs and end-to-end Services. + +Auto ("ONAP-Automated OPNFV") will focus on ONAP component integration and verification with OPNFV reference platforms/scenarios, through primarily a post-install process in order to avoid impact to OPNFV installer projects. As much as possible, this will use a generic installation/integration process (not specific to any OPNFV installer's technology). + +* `ONAP <https://www.onap.org/`_ (a Linux Foundation Project) is an open source software platform that delivers robust capabilities for the design, creation, orchestration, monitoring, and life cycle management of Software-Defined Networks (SDNs). + +While all of ONAP is in scope, as it proceeds, the project will focus on specific aspects of this integration and verification in each release. Some example topics and work items include: + +* How ONAP meets VNFM standards, and interacts with VNFs from different vendors +* How ONAP SDN-C uses OPNFV existing features, e.g. NetReady, in a two-layer controller architecture in which the upper layer (global controller) is replaceable, and the lower layer can use different vendor’s local controller to interact with SDN-C +* What data collection interface VNF and controllers provide to ONAP DCAE, and (through DCAE), to closed-loop control functions such as Policy Tests which verify interoperability of ONAP automation/lifecycle features with specific NFVI and VIM features, as prioritized by the project with technical community and EUAG input. Examples include: + + * Abstraction of networking tech/features e.g. through NetReady/Gluon + * Blueprint-based VNF deployment (HOT, TOSCA, YANG) + * Application level configuration and lifecycle through YANG (for any aspects depending upon OPNFV NFVI+VIM components) + * Policy (through DCAE) + * Telemetry (through VES/DCAE) + +Initial areas of focus for Auto (in orange dotted lines; this scope can be expanded for future releases). It is understood that: + +* ONAP scope extends beyond the lines drawn below +* ONAP architecture does not necessarily align with the ETSI NFV inspired diagrams this is based upon + +.. image:: auto-proj-rn01.png + + +Testability: + +* Tests will be developed for use cases within the project scope. +* In future releases, tests will be added to Functest runs for supporting scenarios. + +Auto’s goals include the standup and tests for integrated ONAP-Cloud platforms (“Cloud” here being OPNFV “scenarios” or other cloud environments). Thus, the artifacts would be tools to deploy ONAP (leveraging OOM whenever possible (starting with Beijing release of ONAP), and a preference for the containerized version of ONAP), to integrate it with clouds, to onboard and deploy test VNFs, to configure policies and closed-loop controls, and to run use-case defined tests against that integrated environment. OPNFV scenarios would be a possible component in the above. + +Auto currently defines three use cases: Edge Cloud, Resiliency Improvements, and Enterprise vCPE. These use cases aim to show: + +* increased autonomy of Edge Cloud management (automation, catalog-based deployment) +* increased resilience (i.e. fast VNF recovery in case of failure or problem, thanks to closed-loop control) +* enterprise-grade performance of vCPEs (certification during onboarding, then real-time performance assurance with SLAs and HA). + +The use cases define test cases, which initially will be independent, but which might eventually be integrated to FuncTest. + +Additional use cases can be added in the future, such as vIMS (example: project Clearwater). + +Target architectures include x86 and Arm. + +An ONAP instance (without DCAE) has been installed over Kubernetes on bare metal on an x86 pod of 6 servers at UNH IOL. +Onboarding of 2 VNFs is in progress: a vCPE and a vFW. + +Integration with Arm servers has started (exploring binary compatibility): + +* Openstack is currently installed on a 6-server pod of Arm servers +* a Kubernetes cluster is installed there as well, for another instance of ONAP on Arm servers +* An additional set of 14 Arm servers is in the process of being deployed at UNH, for increased capacity +* LaaS (Lab as a Service) resources are also used (hpe16, hpe17, hpe19) + +Test case implementation for the three use cases has started. + + +Release Data +============ + ++--------------------------------------+--------------------------------------+ +| **Project** | Fraser/auto/auto@opnfv | +| | | ++--------------------------------------+--------------------------------------+ +| **Repo/commit-ID** | | +| | | ++--------------------------------------+--------------------------------------+ +| **Release designation** | Fraser 6.0 | +| | | ++--------------------------------------+--------------------------------------+ +| **Release date** | 2018-04-20 | +| | | ++--------------------------------------+--------------------------------------+ +| **Purpose of the delivery** | Official OPNFV release | +| | | ++--------------------------------------+--------------------------------------+ + +Version change +^^^^^^^^^^^^^^ + +Module version changes +~~~~~~~~~~~~~~~~~~~~~~ +- There have been no version changes. + + +Document version changes +~~~~~~~~~~~~~~~~~~~~~~~~ +- There have been no version changes. + + +Reason for version +^^^^^^^^^^^^^^^^^^ +Feature additions +~~~~~~~~~~~~~~~~~ + +Initial release, with use case descriptions, release plan, and in-progress test cases and ONAP installations. + + +**JIRA TICKETS:** + ++--------------------------------------+--------------------------------------+ +| **JIRA REFERENCE** | **SLOGAN** | +| | | ++--------------------------------------+--------------------------------------+ +| AUTO-1 | Define Auto-UC-01 Service Provider's | +| | Management of Edge Cloud | ++--------------------------------------+--------------------------------------+ +| AUTO-2 | Define Auto-UC-02 Resilience | +| | Improvements through ONAP | ++--------------------------------------+--------------------------------------+ +| AUTO-7 | Define Auto-UC-03 Enterprise vCPE | +| | | ++--------------------------------------+--------------------------------------+ +| AUTO-4 | Develop test cases for Auto-UC-02 | +| | Resilience Improvements through ONAP | ++--------------------------------------+--------------------------------------+ +| AUTO-8 | Develop test cases for Auto-UC-03 | +| | Enterprise vCPE | ++--------------------------------------+--------------------------------------+ + + +Bug corrections +~~~~~~~~~~~~~~~ + +**JIRA TICKETS:** + ++--------------------------------------+--------------------------------------+ +| **JIRA REFERENCE** | **SLOGAN** | +| | | ++--------------------------------------+--------------------------------------+ +| | | +| | | ++--------------------------------------+--------------------------------------+ +| | | +| | | ++--------------------------------------+--------------------------------------+ + +Deliverables +============ + +Software deliverables +^^^^^^^^^^^^^^^^^^^^^ + +Initial release: in-progress install scripts and test case implementations. + + +Documentation deliverables +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Initial versions of: + +* User guide `OPNFV User and Configuration Guide <http://docs.opnfv.org/en/latest/release/userguide.introduction.html>`_ +* Release notes (this document) + + + +Known Limitations, Issues and Workarounds +========================================= + +System Limitations +^^^^^^^^^^^^^^^^^^ + +* ONAP still to be validated for Arm servers +* DCAE still to be validated for Kubernetes + + + +Known issues +^^^^^^^^^^^^ + +None at this point. + + +**JIRA TICKETS:** + ++--------------------------------------+--------------------------------------+ +| **JIRA REFERENCE** | **SLOGAN** | +| | | ++--------------------------------------+--------------------------------------+ +| | | +| | | ++--------------------------------------+--------------------------------------+ +| | | +| | | ++--------------------------------------+--------------------------------------+ + +Workarounds +^^^^^^^^^^^ + +None at this point. + + + +Test Result +=========== + +None at this point. + + + ++--------------------------------------+--------------------------------------+ +| **TEST-SUITE** | **Results:** | +| | | ++--------------------------------------+--------------------------------------+ +| | | +| | | ++--------------------------------------+--------------------------------------+ +| | | +| | | ++--------------------------------------+--------------------------------------+ + +References +========== + +For more information on the OPNFV Fraser release, please see: +http://opnfv.org/fraser + +Auto Wiki: +https://wiki.opnfv.org/pages/viewpage.action?pageId=12389095 + diff --git a/docs/release/release-notes/auto-proj-rn01.png b/docs/release/release-notes/auto-proj-rn01.png Binary files differnew file mode 100644 index 0000000..65e4aa6 --- /dev/null +++ b/docs/release/release-notes/auto-proj-rn01.png diff --git a/docs/release/release-notes/index.rst b/docs/release/release-notes/index.rst new file mode 100644 index 0000000..7a70167 --- /dev/null +++ b/docs/release/release-notes/index.rst @@ -0,0 +1,15 @@ +.. _auto-releasenotes: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Open Platform for NFV Project, Inc. and its contributors + +=============================================== +OPNFV Auto (ONAP-Automated OPNFV) Release Notes +=============================================== + +.. toctree:: + :numbered: + :maxdepth: 2 + + Auto-release-notes.rst diff --git a/docs/release/userguide/UC01-feature.userguide.rst b/docs/release/userguide/UC01-feature.userguide.rst new file mode 100644 index 0000000..5cf38e1 --- /dev/null +++ b/docs/release/userguide/UC01-feature.userguide.rst @@ -0,0 +1,75 @@ +.. 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) Open Platform for NFV Project, Inc. and its contributors + + +====================================== +Auto User Guide: Use Case 1 Edge Cloud +====================================== + +This document provides the user guide for Fraser release of Auto, +specifically for Use Case 1: Edge Cloud. + + +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. + +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 + + + +Main Success Scenarios: + +* lifecycle management - stop, stop, scale (dependent upon telemetry) + +* recovering from faults (detect, determine appropriate response, act); i.e. exercise closed-loop policy engine in ONAP + + * verify mechanics of control plane interaction + +* collection of telemetry for machine learning + + +Details on the test cases corresponding to this use case: + +* Environment check + + * Basic environment check: Create test script to check basic VIM (OpenStack), ONAP, and VNF are up and running + +* VNF lifecycle management + + * VNF Instance Management: Validation of VNF Instance Management which includes VNF instantiation, VNF State Management and termination + + * Tacker Monitoring Driver (VNFMonitorPing): + + * Write Tacker Monitor driver to handle monitor_call and based on return state value create custom events + * If Ping to VNF fails, trigger below events + + * Event 1 : Collect failure logs from VNF + * Event 2 : Soft restart/respawn the VNF + + * Integrate with Telemetry + + * Create TOSCA template policies to implement ceilometer data collection service + * Collect CPU utilization data, compare with threshold, and perform action accordingly (respawn, scale-in/scale-out) + + + +Test execution high-level description +===================================== + +<TBC> + diff --git a/docs/release/userguide/UC02-feature.userguide.rst b/docs/release/userguide/UC02-feature.userguide.rst new file mode 100644 index 0000000..0ecb7de --- /dev/null +++ b/docs/release/userguide/UC02-feature.userguide.rst @@ -0,0 +1,134 @@ +.. 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) 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. + + +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, 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). + + +Preconditions: + +#. hardware environment in which Edge cloud may be deployed +#. 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 +#. 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. + +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 + +Description of simulated problems/challenges: + +* Physical Infra Failure + + * Migration upon host failure: Compute host power is interrupted, and affected workloads are migrated to other available hosts. + * Migration upon disk failure: Disk volumes are unmounted, and affected workloads are migrated to other available hosts. + * Migration upon link failure: Traffic on links is interrupted/corrupted, and affected workloads are migrated to other available hosts. + * Migration upon NIC failure: NIC ports are disabled by host commands, and affected workloads are migrated to other available hosts. + +* Virtual Infra Failure + + * OpenStack compute host service fail: Core OpenStack service processes on compute hosts are terminated, and auto-restored, or affected workloads are migrated to other available hosts. + * SDNC service fail: Core SDNC service processes are terminated, and auto-restored. + * OVS fail: OVS bridges are disabled, and affected workloads are migrated to other available hosts. + * etc. + +* Security + + * Host tampering: Host tampering is detected, the host is fenced, and affected workloads are migrated to other available hosts. + * Host intrusion: Host intrusion attempts are detected, an offending workload, device, or flow is identified and fenced, and as needed affected workloads are migrated to other available hosts. + * Network intrusion: Network intrusion attempts are detected, and an offending flow is identified and fenced. + + + + +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). + +.. 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. + +.. image:: auto-UC02-pattern.jpg + + +Test design: data model, implementation modules +=============================================== + +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) +* 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). + +.. 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 +maintained as benchmarks. + diff --git a/docs/release/userguide/UC03-feature.userguide.rst b/docs/release/userguide/UC03-feature.userguide.rst new file mode 100644 index 0000000..5f28158 --- /dev/null +++ b/docs/release/userguide/UC03-feature.userguide.rst @@ -0,0 +1,79 @@ +.. 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) Open Platform for NFV Project, Inc. and its contributors + + +=========================================== +Auto User Guide: Use Case 3 Enterprise vCPE +=========================================== + +This document provides the user guide for Fraser release of Auto, +specifically for Use Case 3: Enterprise vCPE. + + +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). + +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. + +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). + +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: + +#. hardware environment in which Edge cloud may be deployed +#. an Edge cloud has been deployed and is ready for operation +#. enterprise edge devices, such as ThinCPE, have access to the Edge cloud with WAN interfaces +#. ONAP components (MSO, SDN-C, APP-C and VNFM) have been deployed onto a cloud and are interfaced (i.e. provisioned for API access) to the Edge cloud + + +Main Success Scenarios: + +* VNF spin-up + + * vCPE spin-up: MSO calls the VNFM to spin up a vCPE instance from the catalog and then updates the active VNF list + * vFW spin-up: MSO calls the VNFM to spin up a vFW instance from the catalog and then updates the active VNF list + +* site2site + + * L3VPN service subscribing: MSO calls the SDNC to create VXLAN tunnels to carry L2 traffic between client's ThinCPE and SP's vCPE, and enables vCPE to route between different sites. + * L3VPN service unsubscribing: MSO calls the SDNC to destroy tunnels and routes, thus disable traffic between different sites. + + +See `ONAP description of vCPE use case <https://wiki.onap.org/display/DW/Use+Case+proposal%3A+Enterprise+vCPE>`_ for more details, including MSCs. + + +Details on the test cases corresponding to this use case: + +* VNF Management + + * Spin up a vCPE instance: Spin up a vCPE instance, by calling NBI of the orchestrator. + * 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. + +* Internet as a Service + + * Subscribe to an Internet service: Subscribe to an Internet service, by calling NBI of the orchestrator. + * Unsubscribe to an Internet service: Unsubscribe to an Internet service, by calling NBI of the orchestrator. + + +Test execution high-level description +===================================== + +<TBC> + diff --git a/docs/release/userguide/auto-UC02-control-loop-flow.png b/docs/release/userguide/auto-UC02-control-loop-flow.png Binary files differnew file mode 100644 index 0000000..b234ece --- /dev/null +++ b/docs/release/userguide/auto-UC02-control-loop-flow.png diff --git a/docs/release/userguide/auto-UC02-data1.jpg b/docs/release/userguide/auto-UC02-data1.jpg Binary files differnew file mode 100644 index 0000000..02a60ba --- /dev/null +++ b/docs/release/userguide/auto-UC02-data1.jpg diff --git a/docs/release/userguide/auto-UC02-data2.jpg b/docs/release/userguide/auto-UC02-data2.jpg Binary files differnew file mode 100644 index 0000000..7096c96 --- /dev/null +++ b/docs/release/userguide/auto-UC02-data2.jpg diff --git a/docs/release/userguide/auto-UC02-data3.jpg b/docs/release/userguide/auto-UC02-data3.jpg Binary files differnew file mode 100644 index 0000000..8e8921d --- /dev/null +++ b/docs/release/userguide/auto-UC02-data3.jpg diff --git a/docs/release/userguide/auto-UC02-module1.jpg b/docs/release/userguide/auto-UC02-module1.jpg Binary files differnew file mode 100644 index 0000000..184ab95 --- /dev/null +++ b/docs/release/userguide/auto-UC02-module1.jpg diff --git a/docs/release/userguide/auto-UC02-module2.jpg b/docs/release/userguide/auto-UC02-module2.jpg Binary files differnew file mode 100644 index 0000000..b95f42d --- /dev/null +++ b/docs/release/userguide/auto-UC02-module2.jpg diff --git a/docs/release/userguide/auto-UC02-pattern.jpg b/docs/release/userguide/auto-UC02-pattern.jpg Binary files differnew file mode 100644 index 0000000..b2c9dee --- /dev/null +++ b/docs/release/userguide/auto-UC02-pattern.jpg diff --git a/docs/release/userguide/auto-UC02-preparation.jpg b/docs/release/userguide/auto-UC02-preparation.jpg Binary files differnew file mode 100644 index 0000000..e2c0ba5 --- /dev/null +++ b/docs/release/userguide/auto-UC02-preparation.jpg diff --git a/docs/release/userguide/auto-UC02-testcases.jpg b/docs/release/userguide/auto-UC02-testcases.jpg Binary files differnew file mode 100644 index 0000000..ccb676f --- /dev/null +++ b/docs/release/userguide/auto-UC02-testcases.jpg diff --git a/docs/release/userguide/index.rst b/docs/release/userguide/index.rst new file mode 100644 index 0000000..7cfbe94 --- /dev/null +++ b/docs/release/userguide/index.rst @@ -0,0 +1,27 @@ +.. _auto-userguide: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Open Platform for NFV Project, Inc. and its contributors + +============================================ +OPNFV Auto (ONAP-Automated OPNFV) User Guide +============================================ + +.. The feature user guide should provide an OPNFV user with enough information to +.. use the features provided by the feature project in the supported scenarios. +.. This guide should walk a user through the usage of the features once a scenario +.. has been deployed and is active according to the installation guide provided +.. by the installer project. + +.. toctree:: + :numbered: + :maxdepth: 2 + + UC01-feature.userguide.rst + UC02-feature.userguide.rst + UC03-feature.userguide.rst + +.. The feature.userguide.rst files should contain the text for this document +.. additional documents can be added to this directory and added in the right order +.. to this file as a list below. |
