diff options
| -rw-r--r-- | docs/docs_5G_oof_pci.rst | 91 | ||||
| -rw-r--r-- | docs/docs_CCVPN.rst | 163 | ||||
| -rw-r--r-- | docs/docs_E2E_network_slicing.rst | 85 | ||||
| -rw-r--r-- | docs/docs_vfw.rst | 2 | ||||
| -rw-r--r-- | docs/docs_vfw_edgex_k8s.rst | 8 | ||||
| -rw-r--r-- | docs/docs_vlb.rst | 26 | ||||
| -rw-r--r-- | docs/index.rst | 1 | ||||
| -rw-r--r-- | docs/integration-labs.rst | 4 | ||||
| -rw-r--r-- | docs/integration-missions.rst | 2 | ||||
| -rw-r--r-- | docs/integration-resources.rst | 2 | ||||
| -rw-r--r-- | docs/integration-tests.rst | 24 | ||||
| -rw-r--r-- | docs/integration-tooling.rst | 185 | ||||
| -rw-r--r-- | docs/release-notes.rst | 2 |
13 files changed, 377 insertions, 218 deletions
diff --git a/docs/docs_5G_oof_pci.rst b/docs/docs_5G_oof_pci.rst index 8edabf40c..c89d20e1c 100644 --- a/docs/docs_5G_oof_pci.rst +++ b/docs/docs_5G_oof_pci.rst @@ -1,36 +1,23 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. http://creativecommons.org/licenses/by/4.0 -.. contents:: - :depth: 3 -.. - .. _docs_5G_oof_pci: - OOF-PCI -------- - Description ~~~~~~~~~~~ -The 5G OOF-PCI use case is an implementation of a SON (Self-Organizing Networks) algorithm - -for Physical Cell ID (PCI) optimization and the centralized Automatic Neighbor Relations - +The 5G OOF-PCI use case is an implementation of a **SON (Self-Organizing Networks)** +algorithm for Physical Cell ID (PCI) optimization and the centralized Automatic Neighbor Relations (ANR) function (blacklisting a neighbor for handovers) in a 4G/5G network using the ONAP +Optimization Framework (OOF). -Optimization Framework (OOF). This use case began with the implementation of PCI - -optimization in Casablanca. In Dublin release, the SON-Handler MS was onboarded asa - -micro-service in DCAE. Enhancements were made to Policy and SDN-C components. Further - -details of Dublin release scope and impacts for this use case are described in: - -https://docs.onap.org/en/dublin/submodules/integration.git/docs/docs_5G_oof_pci.html#docs-5g-oof-pci - +The use case is a multi-releases effort initiated in Dublin release. +This use case began with the implementation of PCI optimization in Casablanca. +In Dublin release, the SON-Handler MS was onboarded as a +micro-service in DCAE. Enhancements were made to Policy and SDN-C components. In Frankfurt release, the following are the main enhancements: @@ -40,25 +27,13 @@ In Frankfurt release, the following are the main enhancements: during PCI optimization) are considered during the PCI optimization. - In addition, the first step towards O-RAN alignment is being taken with SDN-C (R) being able to receive a DMaaP message containing configuration updates (which would be triggered when a neighbor-list-change occurs in the RAN - and is communicated to ONAP over VES). Details of this implementation is available at: - https://wiki.onap.org/display/DW/CM+Notification+Support+in+ONAP - - - The end-to-end setup for the use case requires a Config DB which stores the cell related details of the RAN. - - This is updated by SDN-C (R), and is accessed by SON-Handler MS and OOF for fetching, e.g., neighbor list, PNF id, etc. - - - The Config DB implementation is available at: - - https://github.com/onap-oof-pci-poc/sdnc/tree/master/ConfigDB/Dublin. - + and is communicated to ONAP over VES). `Details of this implementation <https://wiki.onap.org/display/DW/CM+Notification+Support+in+ONAP>`_ +The end-to-end setup for the use case requires a Config DB which stores the cell related details of the RAN. +This is updated by SDN-C (R), and is accessed by SON-Handler MS and OOF for fetching (e.g., neighbor list, PNF id, etc): - Swagger JSON API documentation can be found at: - - https://github.com/onap-oof-pci-poc/sdnc/blob/master/ConfigDB/Dublin/SDNC_ConfigDB_API_v3.0.0.json. - +- `The Config DB implementation <https://github.com/onap-oof-pci-poc/sdnc/tree/master/ConfigDB/Dublin>`_ +- `Swagger JSON API documentation <https://github.com/onap-oof-pci-poc/sdnc/blob/master/ConfigDB/Dublin/SDNC_ConfigDB_API_v3.0.0.json>`_ As part of this use case work, a RAN Simulator providing a simulated Radio Access Network (RAN) with a number of netconf servers simulating PNF elements has been implemented. The @@ -70,55 +45,39 @@ functionality of the RAN Simulator includes: All above functionality are enabled using a simple UI. -All details regarding the use case for Frankfurt can be found here: - -https://wiki.onap.org/display/DW/OOF+%28SON%29+in+R5+El+Alto%2C+OOF+%28SON%29+in+R6+Frankfurt - -The main use case page is: - -https://wiki.onap.org/display/DW/5G+-+OOF+%28ONAP+Optimization+Framework%29+and+PCI+%28Physical+Cell+ID%29+Optimization - +Please see also `OOF (SON) wiki page <https://wiki.onap.org/display/DW/5G+-+OOF+%28ONAP+Optimization+Framework%29+and+PCI+%28Physical+Cell+ID%29+Optimization>`_. +Additional information are available related to previous releases can be found +in `El Alto & Frankfurt OOF (SON) wiki page <https://wiki.onap.org/display/DW/OOF+%28SON%29+in+R5+El+Alto%2C+OOF+%28SON%29+in+R6+Frankfurt>`_. How to Use ~~~~~~~~~~ The OOF-PCI use case is implemented in the Rutgers University (Winlab) ONAP Wireless Lab (OWL). - -For details, please see: https://wiki.onap.org/pages/viewpage.action?pageId=45298557. +For details, please see +`lab details <https://wiki.onap.org/pages/viewpage.action?pageId=45298557>`_. This page includes instructions for access to the lab. Setup and testing is done manually up to now. For all instructions about installing the components, please see: -Installation: https://wiki.onap.org/display/DW/Demo+setup+steps+for+Frankfurt - - -Son-Handler installation: - -https://docs.onap.org/projects/onap-dcaegen2/en/frankfurt/sections/services/son-handler/installation.html?highlight=dcaegen2 - +- `Wiki Installation page <https://wiki.onap.org/display/DW/Demo+setup+steps+for+Frankfurt>`_ +- `Son-Handler installation <https://docs.onap.org/projects/onap-dcaegen2/en/frankfurt/sections/services/son-handler/installation.html?highlight=dcaegen2>`_ Test Status and Plans ~~~~~~~~~~~~~~~~~~~~~ -For Frankfurt release, the enhancements described above were implemented. OOF was enhanced - -with handling cells with fixed PCI values during the optimization, SON-Handler MS was - -functionally enhanced for adaptive SON functionality, SDN-C (R) was enhanced to include - -handling of DMaaP message for config changes in the RAN, and Policy was also enhanced with - -Control Loop Co-ordination function. - -To see information about test plans, please see https://wiki.onap.org/display/DW/Testing. +OOF was enhanced with handling cells with fixed PCI values during the optimization, +SON-Handler MS was functionally enhanced for adaptive SON functionality, SDN-C (R) +was enhanced to include handling of DMaaP message for config changes in the RAN, +and Policy was also enhanced with Control Loop Co-ordination function. +See `test plans <https://wiki.onap.org/display/DW/Testing>`_ for details. Known Issues and Resolutions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (a) It is intended to have the RAN Simulator support sufficient Honeycomb netconf server instances to simulate 2000 cells. - However, this number may be lower if there are hardware limitatons. + However, this number may be lower if there are hardware limitations. (b) For Control Loop Co-ordination, the denial of a second Control Loop based on Target Lock (i.e., when a second Control Loop tries to operate on the same target (in this case, a PNF) is successfully tested. The CLC is also applied at Control Loop level only. However, some code updates are required in Policy to properly update the Operations History DB entry, and diff --git a/docs/docs_CCVPN.rst b/docs/docs_CCVPN.rst index 557ec4d0e..e304808ce 100644 --- a/docs/docs_CCVPN.rst +++ b/docs/docs_CCVPN.rst @@ -9,13 +9,13 @@ CCVPN (Cross Domain and Cross Layer VPN) Update for Guilin Release ~~~~~~~~~~~~~~~~~~~~~~~~~ -In Guilin Release, MDONS Extension feature is introduced. +In Guilin Release, **MDONS** Extension feature is introduced. -In addition to the MDONS extension, CCVPN has also developed an -IETF/ACTN-based Transport Slicing solution (REQ-347). This development -enabled ONAP to offer the TN NSSMF functionality, which was used by -the E2E Network Slicing use case (REQ-342). The solution was built -upon the existing IETF/ACTN E-LINE over OTN NNI feature developed in Frankfurt release. +In addition to the MDONS extension, CCVPN has also developed an +IETF/ACTN-based Transport Slicing solution (REQ-347). This development +enabled ONAP to offer the TN NSSMF functionality, which was used by +the E2E Network Slicing use case (REQ-342). The solution was built +upon the existing IETF/ACTN E-LINE over OTN NNI feature developed in Frankfurt release. Guilin Scope and Impacted modules ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -26,7 +26,7 @@ MDONS Extension implementation for the Frankfurt release will incorporate the fo - Support Closed Loop sub-use case Impacted ONAP modules include: OOF, SDN-C, SO and Holmes -Wiki link reference: https://wiki.onap.org/display/DW/MDONS+Extension+in+R7 +`Wiki link reference <https://wiki.onap.org/display/DW/MDONS+Extension+in+R7>`_ Transport Slicing in Guilin release has implemented the following TN NSSMF functionality: @@ -35,7 +35,7 @@ Transport Slicing in Guilin release has implemented the following TN NSSMF funct - Activate TN NSSI - Deactivate TN NSSI -The Tranport Slicing implementaion has made code changes in the following modules: +The Tranport Slicing implementation has made code changes in the following modules: - AAI (Schema changes only) - UUI @@ -47,49 +47,53 @@ The Tranport Slicing implementaion has made code changes in the following module Functional/Integration Test Cases ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For integration test case and description of MDONS extension, refer to this following -wiki-page: -https://wiki.onap.org/display/DW/Integration+Test+Cases+-+MDONS+Extension -For integration test case and description of Transport Slicing, refer to this following -wiki-pages: -https://wiki.onap.org/display/DW/CCVPN+-+Transport+Slicing+integration+test+plan+for+Guilin+release -https://wiki.onap.org/display/DW/E2E+Network+Slicing+Use+Case+in+R7+Guilin +For integration test case and description of MDONS extension, refer to this +`following wiki-page <https://wiki.onap.org/display/DW/Integration+Test+Cases+-+MDONS+Extension>`_. + +For integration test case and description of Transport Slicing: + +- `Guilin Test plan <https://wiki.onap.org/display/DW/CCVPN+-+Transport+Slicing+integration+test+plan+for+Guilin+release>`_ +- `Guilin E2E Network Slicing <https://wiki.onap.org/display/DW/E2E+Network+Slicing+Use+Case+in+R7+Guilin>`_ Installation Procedure ~~~~~~~~~~~~~~~~~~~~~~ -For MDONS extention, The integration test environment is established to have ONAP instance with Guilin + +For MDONS extension, the integration test environment is established to have ONAP instance with Guilin release interfacing to 3rd party transport domain controllers. One controller instance manages OpenROADM OTN topology and the other 2 instances manage TAPI OTN topology. L0 infrastructure and WDM services are pre-provisioned to support L1 topology discovery and OTN service orchestration from ONAP. -For Transport Slicing, the installation procedure is similiar to that of the E2E +For Transport Slicing, the installation procedure is similar to that of the E2E Network Slicing use case. In other words, we need to bring up the required modules including SDC, SO, A&AI, UUI and OOF. We also need to configure these modules along with the mandatory common modules such as DMaaP. -Testing Procedure -~~~~~~~~~~~~~~~~~ -Testing procedure for MDONS extention: -https://wiki.onap.org/display/DW/Integration+Test+Cases+-+MDONS+Extension +Testing Procedures +~~~~~~~~~~~~~~~~~~ + +The testing procedure is described in: -Testing procedure for Transport Slicing: -https://wiki.onap.org/display/DW/CCVPN+-+Transport+Slicing+integration+test+plan+for+Guilin+release +- `Testing procedure for MDONS extension <https://wiki.onap.org/display/DW/Integration+Test+Cases+-+MDONS+Extension>`_ +- `Testing procedure for Transport Slicing <https://wiki.onap.org/display/DW/CCVPN+-+Transport+Slicing+integration+test+plan+for+Guilin+release>`_ Update for Frankfurt release ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + In Frankfurt, we introduced two extensions in CCVPN use case. One is E-LINE service over OTN NNI handover, another is the multi domain optical service which aims to provide end to end layer 1 service. E-LINE over OTN NNI ~~~~~~~~~~~~~~~~~~~ + Description ~~~~~~~~~~~ + It is considered a typical scenario for operators to use OTN to interconnect its multiple transport network domains. Hence the capabilities of orchestrating end-to-end E-LINE services across the domains over OTN is important for ONAP. When operating with multiple domains with multi vendor solutions, it is also important to define and use standard and open -interfaces, such as the IETF ACTN-based transport YANG models(https://tools.ietf.org/html/rfc8345), as the southbound interface +interfaces, such as the IETF ACTN-based transport `YANG models <https://tools.ietf.org/html/rfc8345>`_, as the southbound interface of ONAP, in order to ensure interoperability. The SOTN NNI use-case aims to automate the design, service provision by independent operational entities within a service provider network by delivering E-Line over OTN orchestration capabilities into ONAP. SOTN NNI extends upon the CCVPN use-case by incorporating support for L1/L2 network management capabilities leveraging open standards & common @@ -97,6 +101,7 @@ data models. Frankfurt Scope and Impacted modules ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + The Frankfurt demonstration includes L1(OTN) and L2(ETH) Topology discovery from multiple domains controllers with in an operator and provide VPN service provision in OTN and ETH network. @@ -104,10 +109,11 @@ The ONAP components involved in this use case are: SDC, A&AI, UUI, SO, SDNC, OOF Functional Test Cases ~~~~~~~~~~~~~~~~~~~~~ + Usecase specific developments have been realized in SO, OOF, AAI, SDNC and UUI ONAP components.. -All test case covered by this use case: -https://wiki.onap.org/display/DW/E-LINE+over+OTN+Inter+Domain+Test+Cases +See the `wiki <https://wiki.onap.org/display/DW/E-LINE+over+OTN+Inter+Domain+Test+Cases>`_ +for details. Testing Procedure ~~~~~~~~~~~~~~~~~ @@ -115,22 +121,24 @@ Design time SOTNVPNInfraService service design in SDC and distribute to AAI and SO. Run Time: -All operation will be triggered by UUI, including service creation and termination, link management and topology network display. - -More details can be found here: -https://wiki.onap.org/display/DW/E-LINE+over+OTN+Inter+Domain+Test+Cases +All operation will be triggered by UUI, including service creation and termination, +link management and topology network display: -Test status can be found here: -https://wiki.onap.org/display/DW/2%3A+Frankfurt+Release+Integration+Testing+Status +- `E-LINE over OTN Inter Doamin Test Cases <https://wiki.onap.org/display/DW/E-LINE+over+OTN+Inter+Domain+Test+Cases>`_ +- `Testing status <https://wiki.onap.org/display/DW/2%3A+Frankfurt+Release+Integration+Testing+Status>`_ MDONS (Multi-Domain Optical Network Services) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + Overall Description ~~~~~~~~~~~~~~~~~~~ -The MDONS use-case aims to automate the design, activation & operations resulting from an optical transport (L0/L1) service request exchange between service providers and/or independent operational entities within a service provider network by delivering E2E optical orchestration capabilities into ONAP. MDONS extends upon the CCVPN use-case by incorporating support for L0/L1 network management capabilities leveraging open standards & common data models defined by OpenROADM, Transport-API & MEF. + +The MDONS use-case aims to automate the design, activation & operations resulting +from an optical transport (L0/L1) service request exchange between service providers and/or independent operational entities within a service provider network by delivering E2E optical orchestration capabilities into ONAP. MDONS extends upon the CCVPN use-case by incorporating support for L0/L1 network management capabilities leveraging open standards & common data models defined by OpenROADM, Transport-API & MEF. Frankfurt Scope and Impacted modules ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + MDONS implementation for the Frankfurt release will incorporate the following: - Design & modelling of optical services based on MEF L1 subscriber & operator properties - E2E optical service workflow definitions for service instantiation & deletion @@ -138,23 +146,32 @@ MDONS implementation for the Frankfurt release will incorporate the following: - Optical Transport domain management (topology, resource onboarding) through standard models / APIs - OpenROADM, T-API Impacted ONAP modules include: A&AI, SDC, SDN-C, SO, UUI -OpenROADM reference: https://github.com/OpenROADM/OpenROADM_MSA_Public -ONF Transport-API (TAPI): https://github.com/OpenNetworkingFoundation/TAPI -MEF: https://wiki.mef.net/display/CESG/MEF+63+-+Subscriber+Layer+1+Service+Attributes +References: + +- `OpenROADM reference <https://github.com/OpenROADM/OpenROADM_MSA_Public>`_ +- `ONF Transport-API (TAPI) <https://github.com/OpenNetworkingFoundation/TAPI>`_ +- `MEF <https://wiki.mef.net/display/CESG/MEF+63+-+Subscriber+Layer+1+Service+Attributes>`_ Functional/Integration Test Cases ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For integration test case and description, refer to this following wiki-page: -https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case + +For integration test case and description, refer to this following +`wiki-page <https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case>`_. Installation Procedure ~~~~~~~~~~~~~~~~~~~~~~ -The integration test environment is established to have ONAP instance with Frankfurt release interfacing to 3rd party transport domain controllers. One controller instance manages OpenROADM OTN topology and the other 2 instances manage TAPI OTN topology. L0 infrastructure and WDM services are pre-provisioned to support L1 topology discovery and OTN service orchestration from ONAP. + +The integration test environment is established to have ONAP instance with +Frankfurt release interfacing to 3rd party transport domain controllers. +One controller instance manages OpenROADM OTN topology and the other 2 instances +manage TAPI OTN topology. L0 infrastructure and WDM services are pre-provisioned +to support L1 topology discovery and OTN service orchestration from ONAP. Testing Procedure ~~~~~~~~~~~~~~~~~ -Test environment is described in Installation Procedure section and test procedure is described in https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case. +Test environment is described in +`Installation and Test Procedure <https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case>`_. Update for Dublin release ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -164,9 +181,9 @@ Update for Dublin release In Dublin release,the design of CCVPN was optimized by having support of List type of Input in SDC. During onboarding and design phase, one end to end service is created using SDC. This service is composed of these two kinds of resources: -• VPN resource -• Site resource -You can see the details from here https://wiki.onap.org/display/DW/Details+of+Targeted+Service+Template + • VPN resource + • Site resource + See the `wiki <https://wiki.onap.org/display/DW/Details+of+Targeted+Service+Template>`_ for details. 2. Closed Loop in bandwidth adjustment Simulate alarm at the edge site branch and ONAP will execute close-loop automatically and trigger bandwidth to change higher. @@ -174,52 +191,68 @@ Simulate alarm at the edge site branch and ONAP will execute close-loop automati 3. Site Change Site can be add or delete according to the requirements +More information about: -More information about CCVPN in Dublin release:https://wiki.onap.org/pages/viewpage.action?pageId=45296665 -and the test case in Dublin can be found:https://wiki.onap.org/display/DW/CCVPN+Test+Cases+for+Dublin+Release -And test status:https://wiki.onap.org/display/DW/CCVPN+Test+Status +- `CCVPN in Dublin release <https://wiki.onap.org/pages/viewpage.action?pageId=45296665>`_ +- `Dublin test cases <https://wiki.onap.org/display/DW/CCVPN+Test+Cases+for+Dublin+Release>`_ +- `test status <https://wiki.onap.org/display/DW/CCVPN+Test+Status>`_ -Note: CCVPN integration testing coversed service design, service creation and closed-loop bandwidth adjustments in Dublin release. -The service termination and service change will continue to be tested in E release. -During the integration testing, SDC, SO, SDC master branch are used which include the enhanced features for CCVPN use case. +.. note:: + CCVPN integration testing coversed service design, service creation and + closed-loop bandwidth adjustments in Dublin release. + The service termination and service change will continue to be tested in E release. + During the integration testing, SDC, SO, SDC master branch are used which + includes the enhanced features for CCVPN use case. Service used for CCVPN ~~~~~~~~~~~~~~~~~~~~~~ -- SOTNVPNInfraService, SDWANVPNInfraService and SIteService: https://wiki.onap.org/display/DW/CCVPN+Service+Design -- WanConnectionService ( Another way to describe CCVPN in a single service form which based on ONF CIM ): https://wiki.onap.org/display/DW/CCVPN+Wan+Connection+Service+Design +- `SOTNVPNInfraService, SDWANVPNInfraService and SIteService <https://wiki.onap.org/display/DW/CCVPN+Service+Design>`_ +- `WanConnectionService (Another way to describe CCVPN in a single service form which based on ONF CIM <https://wiki.onap.org/display/DW/CCVPN+Wan+Connection+Service+Design>`_ Description ~~~~~~~~~~~ -Cross-domain, cross-layer VPN (CCVPN) is one of the use cases of the ONAP Casablanca release. This release demonstrates cross-operator ONAP orchestration and interoperability with third party SDN controllers and enables cross-domain, cross-layer and cross-operator service creation and assurance. -The demonstration includes two ONAP instances, one deployed by Vodafone and one by China Mobile, both of which orchestrate the respective operator underlay OTN networks and overlay SD-WAN networks and peer to each other for cross-operator VPN service delivery. +Cross-domain, cross-layer VPN (CCVPN) is one of the use cases of the ONAP +Casablanca release. This release demonstrates cross-operator ONAP orchestration +and interoperability with third party SDN controllers and enables cross-domain, +cross-layer and cross-operator service creation and assurance. -The CCVPN Use Case Wiki Page can be found here: https://wiki.onap.org/display/DW/CCVPN%28Cross+Domain+and+Cross+Layer+VPN%29+USE+CASE. +The demonstration includes two ONAP instances, one deployed by Vodafone and one +by China Mobile, both of which orchestrate the respective operator underlay OTN +networks and overlay SD-WAN networks and peer to each other for cross-operator +VPN service delivery. + +`CCVPN Use Case Wiki Page <https://wiki.onap.org/display/DW/CCVPN%28Cross+Domain+and+Cross+Layer+VPN%29+USE+CASE>`_ The projects covered by this use case include: SDC, A&AI, UUI, SO, SDNC, OOF, Policy, DCAE(Holmes), External API, MSB How to Use ~~~~~~~~~~ -Design time -SOTNVPNInfraService, SDWANVPNInfraService and SIteService service Design steps can be found here: https://wiki.onap.org/display/DW/CCVPN+Service+Design -WanConnectionService ( Another way to describe CCVPN in a single service form which based on ONF CIM ): https://wiki.onap.org/display/DW/CCVPN+Wan+Connection+Service+Design + +Design time: + +- `SOTNVPNInfraService, SDWANVPNInfraService and SIteService service Design steps <https://wiki.onap.org/display/DW/CCVPN+Service+Design>`_ +- `WanConnectionService ( Another way to describe CCVPN in a single service form which based on ONF CIM ) <https://wiki.onap.org/display/DW/CCVPN+Wan+Connection+Service+Design>`_ Run Time: -All opertion will be triggerd by UUI, inlcuding service creation and termination, link management and topology network display. + +- All operations will be triggered by UUI, including service creation and termination, + link management and topology network display. -More details can be fonud here: https://wiki.onap.org/display/DW/CCVPN+Test+Guide +See the `wiki <https://wiki.onap.org/display/DW/CCVPN+Test+Guide>`_ for details. Test Status and Plans ~~~~~~~~~~~~~~~~~~~~~ -All test case covered by this use case: https://wiki.onap.org/display/DW/CCVPN+Integration+Test+Case -And the test status can be found: https://wiki.onap.org/display/DW/CCVPN++-Test+Status +- `All test case covered by this use case <https://wiki.onap.org/display/DW/CCVPN+Integration+Test+Case>`_ +- `Test status <https://wiki.onap.org/display/DW/CCVPN++-Test+Status>`_ Known Issues and Resolutions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 1) AAI-1923. Link Management, UUI can't delete the link to external onap otn domain. For the manual steps provided by A&AI team, we should follow the steps as follow @@ -260,7 +293,7 @@ From the above, remove the YOUR_ID_ANY_VALUE and VERTEX_ID with your info. 2) SDC-1955. Site service Distribution To overcome the Service distribution, the SO catalog has to be populated with the model information of the services and resources. -a) Refering to the Csar that is generated in the SDC designed as per the detailes mentioned in the below link: https://wiki.onap.org/display/DW/CCVPN+Service+Design +a) Refering to the Csar that is generated in the SDC designed as per the details mentioned in the below link: https://wiki.onap.org/display/DW/CCVPN+Service+Design b) Download the Csar from SDC thus generated. c) copy the csar to SO sdc controller pod and bpmn pod @@ -279,9 +312,9 @@ d) populate model information to SO db: the db script example can be seen in The same would also be applicable for the integration of the client to create the service and get the details. Currently the testing has been performed using the postman calls to the corresponding APIs. -3) SDC-1955 & SDC-1958. Site serivce parsing Error +3) SDC-1955 & SDC-1958. Site service parsing Error -UUI: stored the csar which created based on beijing release under a fixed directory, If site serive can't parsed by SDC tosca parser, UUI will parse this default csar and get the input parameter +UUI: stored the csar which created based on beijing release under a fixed directory, If site servive can't parsed by SDC tosca parser, UUI will parse this default csar and get the input parameter a) Make an available csar file for CCVPN use case. b) Replace uuid of available files with what existing in SDC. c) Put available csar files in UUI local path (/home/uui). @@ -299,6 +332,6 @@ After SDC distribution success, copy all csar files from so-sdc-controller: Copy csar files, which got from so-sdc-controller, to so-bpmn-infra: - connect to so-bpmn-infra ( eg: kubectl.exe -n onap exec -it dev-so-so-bpmn-infra-54db5cd955-h7f5s -c so-bpmn-infra /bin/sh ) -- check the /app/ASDC deretory, if doesn't exist, create it ( eg: mkdir /app/ASDC -p ) +- check the /app/ASDC directory, if doesn't exist, create it ( eg: mkdir /app/ASDC -p ) - exit from the so-bpmn-infra ( eg: exit ) - copy all csar files to so-bpmn-infra ( eg: kubectl.exe cp service-Siteservice-csar.csar onap/dev-so-so-bpmn-infra-54db5cd955-h7f5s:/app/ASDC/1/service-Siteservice-csar.csar ) diff --git a/docs/docs_E2E_network_slicing.rst b/docs/docs_E2E_network_slicing.rst index e177f8d8b..2e2c8162b 100644 --- a/docs/docs_E2E_network_slicing.rst +++ b/docs/docs_E2E_network_slicing.rst @@ -1,9 +1,6 @@ .. This file is licensed under the CREATIVE COMMONS ATTRIBUTION 4.0 INTERNATIONAL LICENSE .. Full license text at https://creativecommons.org/licenses/by/4.0/legalcode -.. contents:: - :depth: 3 -.. .. _docs_E2E_network_slicing: @@ -13,8 +10,8 @@ E2E Network Slicing Use Case Overall Blueprint ----------------- -The objective of this use case is to realize End-to-End 5G Network -Slicing using ONAP. An End-to-End Network Slice consists of RAN (Radio +The objective of this use case is to realize **End-to-End 5G Network +Slicing** using ONAP. An End-to-End Network Slice consists of RAN (Radio Access Network), Transport Network (TN) and Core Network (CN) slice sub-nets. This use case intends to demonstrate the modeling, orchestration (life cycle and resources) and assurance of a network @@ -46,16 +43,15 @@ key highlights of this use case include: integrators thereby taking into consideration different perspectives and requirements. -This use case is a multi-release effort in ONAP with the first steps +This use case is a multi-releases effort in ONAP with the first steps taken in Frankfurt release. It will continue to expand in scope both in breadth and depth, and along the journey it shall also align with updates to the relevant standards which are also currently evolving. This use case shall also collaborate with other open initiatives such as O-RAN to enable wider adoption and use. -Further details can be obtained from: -https://wiki.onap.org/display/DW/Use+Case+Description+and+Blueprint - +See the `wiki <https://wiki.onap.org/display/DW/Use+Case+Description+and+Blueprint>`_ +for details. Abbreviations ------------- @@ -82,13 +78,13 @@ Abbreviations | NSST | Network Slice Sub-net Template | +---------------+--------------------------------------------+ +Scope +----- -Scope for Frankfurt -------------------- - -To realize the three layers of the slice management function, we need to decide whether to implement CSMF, NSMF or NSMF within ONAP, or use the external CSMF, NSMF or NSSMF. This implies that for ONAP-based network slice management, we have different choices from an architectural perspective. For Frankfurt release, our scope is to implement CSMF and NSMF within ONAP, while connecting to an external Core NSSMF. +To realize the three layers of the slice management function, we need to decide whether to implement CSMF, NSMF or NSMF within ONAP, or use the external CSMF, NSMF or NSSMF. This implies that for ONAP-based network slice management, we have different choices from an architectural perspective. +Our scope was to implement first the CSMF and NSMF functions within ONAP, while connecting to an external Core NSSMF. -From the NSI Life Cycle perspective, the scope for Frankfurt includes NSI design and pre-provision, NSI instantiation and configuration, and NSI activation and deactivation. In particular: +From the NSI Life Cycle perspective, the scope includes NSI design and pre-provision, NSI instantiation and configuration, and NSI activation and deactivation. In particular: - CSMF: Functions of slice service creation, slice service activation and deactivation are implemented. @@ -104,12 +100,11 @@ From the NSI Life Cycle perspective, the scope for Frankfurt includes NSI design To support the above functions, code impacts in U-UI, SO, OOF and ExtAPI components, and schema change in A&AI are implemented. -Further details can be obtained from: -https://wiki.onap.org/display/DW/Proposed+Functions+for+R6+and+Impacted+Modules - +See the `wiki <https://wiki.onap.org/display/DW/Proposed+Functions+for+R6+and+Impacted+Modules>`_ +for details. -Impacted Modules for Frankfurt ------------------------------- +Impacted Modules +---------------- SO ~~ @@ -136,8 +131,8 @@ recalibration of NSI&NSSI selection with manual intervention from the portal. A new SO adapter is created to be the adapter of NSSMF which will interact with external NSSMF for NSSI management. -Further details can be obtained from: -https://wiki.onap.org/display/DW/SO%3A+Impacts+and+Interfaces +See the `wiki <https://wiki.onap.org/display/DW/SO%3A+Impacts+and+Interfaces>`_ +for details. U-UI ~~~~ @@ -165,8 +160,7 @@ statistics of network slices. In this page, the statistics of slice usage (traffic), online users and total bandwidth can be monitored and displayed in the form of pi-charts and lines. -Further details can be obtained from: -https://wiki.onap.org/display/DW/UUI%3A+Impacts +See the `wiki <https://wiki.onap.org/display/DW/UUI%3A+Impacts>`_ for details. OOF ~~~ @@ -191,15 +185,15 @@ adapted for constraints and optimal selection of slice template and slice instance. In case of new NSSI creation, HAS returns appropriate slice profile for the sub-net for which a new NSSI has to be created. -Further details can be obtained from: -https://wiki.onap.org/display/DW/OOF%3A+Impacts+and+Interfaces +See the `wiki <https://wiki.onap.org/display/DW/OOF%3A+Impacts+and+Interfaces>`_ +for details EXT-API ~~~~~~~ -The EXT-API has undergone some minimal enhancements for this use case in -Frankfurt release. A new value “CST” for the serviceType attribute in -the Service Order API has been introduced. +The EXT-API has undergone some minimal enhancements for this use case. +A new value “CST” for the serviceType attribute in the Service Order API has +been introduced. The CSMF Portal in UUI captures the values for the requested serviceCharacteristics that are required as inputs to CST Service model. @@ -217,8 +211,8 @@ for creating the service. As can be seen from above explanation, the existing constructs of ExtAPI has been reused with minor enhancements. -Further details can be obtained from: -https://wiki.onap.org/display/DW/ExtAPI%3A+Impacts+and+Interfaces +See the `wiki <https://wiki.onap.org/display/DW/ExtAPI%3A+Impacts+and+Interfaces>`_ +for details. A&AI ~~~~ @@ -245,10 +239,8 @@ A&AI provides query APIs to CSMF and NSMF, such as: - Query Communication-service-instances/Service-profile-instances/NSI/NSSI - - Query Service-profile-instance by specified Communication-service-instance - - Query NSI by specified Service-profile-instance, query NSSI by specified NSSI. @@ -256,12 +248,10 @@ A&AI also supply creation APIs to SO, such as: - Create Communication-service-profile/Service-profile/Slice-profile, and - - Create relationship between service-instances. -Further details can be obtained from: -https://wiki.onap.org/pages/viewpage.action?pageId=76875989 - +See the `wiki <https://wiki.onap.org/pages/viewpage.action?pageId=76875989>`_ +for details. Functional Test Cases --------------------- @@ -274,32 +264,23 @@ aspects: - Creation of a new customer service via CSMF portal in UUI resulting in creation of a new NSI - - Creation of a new customer service via CSMF portal in UUI resulting in re-use of an existing NSI - - Activation of a customer service via CSMF portal in UUI - - Creation of a new customer service via postman request to EXT-API resulting in creation of a new NSI - - Creation of a new customer service via via postman request to ExtAPI resulting in re-use of an existing NSI - - Manual intervention via NSMF portal during NSI selection (NSI selection adjustment) - - Termination of a NSI and associated NSSI - - Interaction between ONAP and external NSSMF for new core NSSI creation - - Checking inventory updates in AAI for NSIs, service and slice profiles and NSSIs. -Further details can be obtained from: -https://wiki.onap.org/display/DW/Functional+Test+Cases - +See the `wiki <https://wiki.onap.org/display/DW/Functional+Test+Cases>`_ for +details. Operation Guidance ------------------ @@ -317,12 +298,12 @@ optimize the resources required for setting up the use case. This approach will help to install a minimum-scope version ONAP for 5G E2E Slicing use case. -Further details of the installation steps are available at: -https://wiki.onap.org/display/DW/Install+Minimum+Scope+ONAP+for+5G+Network+Slicing - +See the `wiki <https://wiki.onap.org/display/DW/Install+Minimum+Scope+ONAP+for+5G+Network+Slicing>`_ +for details. Configuration aspects ~~~~~~~~~~~~~~~~~~~~~ + The template design, UI configuration, as well as manual configurations for some -of the components are all described in the following wiki page and its sub-pages: -https://wiki.onap.org/display/DW/Operation+Guidance+for+5G+Network+Slicing+Use+Case +of the components are all described in the following +`wiki page and its sub-pages <https://wiki.onap.org/display/DW/Operation+Guidance+for+5G+Network+Slicing+Use+Case>`_ diff --git a/docs/docs_vfw.rst b/docs/docs_vfw.rst index ec46e5c64..f91818125 100644 --- a/docs/docs_vfw.rst +++ b/docs/docs_vfw.rst @@ -109,7 +109,7 @@ At the end of the test , robot sets the streams back to Medium so that it is setup for the next test. For documentation about running the use case manually for previous releases, -please look at the videos and the material available at this `wiki page`__. +please look at the videos and the material available at this `wiki page`_. __ https://wiki.onap.org/display/DW/Running+the+ONAP+Demos diff --git a/docs/docs_vfw_edgex_k8s.rst b/docs/docs_vfw_edgex_k8s.rst index e860feede..02ff713d7 100644 --- a/docs/docs_vfw_edgex_k8s.rst +++ b/docs/docs_vfw_edgex_k8s.rst @@ -202,7 +202,7 @@ Onboard the CSAR ---------------- For onboarding instructions please refer to steps 4-9 from the document -`here <https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging>`__. +`here <https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging>`_. Steps for installing KUD Cloud ------------------------------ @@ -273,14 +273,14 @@ the lab where we tested). This will cause multicloud to add the tenant to the k8s cloud region and then, similarly to #10 in the documentation -`here <https://onap.readthedocs.io/en/casablanca/submodules/integration.git/docs/docs_vfwHPA.html#docs-vfw-hpa>`__, +`here <https://onap.readthedocs.io/en/casablanca/submodules/integration.git/docs/docs_vfwHPA.html#docs-vfw-hpa>`_, the service-subscription can be added to that object. **NOTE:** use same name cloud-region and cloud-owner name An example is shown below for K8s cloud but following the steps 1,2,3 from -`here <https://docs.onap.org/projects/onap-multicloud-framework/en/latest/multicloud-plugin-windriver/UserGuide-MultiCloud-WindRiver-TitaniumCloud.html?highlight=multicloud>`__. +`here <https://docs.onap.org/projects/onap-multicloud-framework/en/latest/multicloud-plugin-windriver/UserGuide-MultiCloud-WindRiver-TitaniumCloud.html?highlight=multicloud>`_. The sample input below is for k8s cloud type. **Step 1**: Cloud Registration/ Create a cloud region to represent the instance @@ -647,7 +647,7 @@ using the Kubernetes API. curl -X GET http://MSB_NODE_IP:30280/api/multicloud-k8s/v1/v1/instance/ZKMTSaxv -`*\ https://github.com/onap/oom/blob/master/kubernetes/multicloud/resources/config/provider-plugin.json <https://github.com/onap/oom/blob/master/kubernetes/multicloud/resources/config/provider-plugin.json>`__ +`*\ https://github.com/onap/oom/blob/master/kubernetes/multicloud/resources/config/provider-plugin.json <https://github.com/onap/oom/blob/master/kubernetes/multicloud/resources/config/provider-plugin.json>`_ Create User parameters ~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/docs_vlb.rst b/docs/docs_vlb.rst index ded308f05..5044d2adc 100644 --- a/docs/docs_vlb.rst +++ b/docs/docs_vlb.rst @@ -15,7 +15,7 @@ Source files Description ~~~~~~~~~~~ -The use case is composed of three VFs: packet generator, load balancer, and DNS server. These VFs run in three separate VMs. The packet generator issues DNS lookup queries that reach the DNS server via the load balancer. DNS replies reach the packet generator via the load balancer as well. The load balancer reports the average amount of traffic per DNS over a time interval to the DCAE collector. When the average amount of traffic per DNS server crosses a predefined threshold, the closed-loop is triggered and a new DNS server is instantiated. +The use case is composed of three VFs: packet generator, load balancer, and DNS server. These VFs run in three separate VMs. The packet generator issues DNS lookup queries that reach the DNS server via the load balancer. DNS replies reach the packet generator via the load balancer as well. The load balancer reports the average amount of traffic per DNS over a time interval to the DCAE collector. When the average amount of traffic per DNS server crosses a predefined threshold, the closed-loop is triggered and a new DNS server is instantiated. To test the application, make sure that the security group in OpenStack has ingress/egress entries for protocol 47 (GRE). The user can run a DNS query from the packet generator VM: @@ -23,7 +23,7 @@ To test the application, make sure that the security group in OpenStack has ingr dig @vLoadBalancer_IP host1.dnsdemo.onap.org -The output below means that the load balancer has been set up correctly, has forwarded the DNS queries to one DNS instance, and the packet generator has received the DNS reply message. +The output below means that the load balancer has been set up correctly, has forwarded the DNS queries to one DNS instance, and the packet generator has received the DNS reply message. :: @@ -34,26 +34,26 @@ The output below means that the load balancer has been set up correctly, has for ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31892 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; WARNING: recursion requested but not available - + ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;host1.dnsdemo.onap.org. IN A - + ;; ANSWER SECTION: host1.dnsdemo.onap.org. 604800 IN A 10.0.100.101 - + ;; AUTHORITY SECTION: dnsdemo.onap.org. 604800 IN NS dnsdemo.onap.org. - + ;; ADDITIONAL SECTION: dnsdemo.onap.org. 604800 IN A 10.0.100.100 - + ;; Query time: 0 msec ;; SERVER: 192.168.9.111#53(192.168.9.111) ;; WHEN: Fri Nov 10 17:39:12 UTC 2017 ;; MSG SIZE rcvd: 97 - + Closedloop for vLoadBalancer/vDNS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -70,9 +70,9 @@ To change the volume of queries generated by the packet generator, run the follo :: - curl -X PUT -H "Authorization: Basic YWRtaW46YWRtaW4=" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{"pg-streams":{"pg-stream": [{"id":"dns1", "is-enabled":"true"}]}}' "http://PacketGen_IP:8183/restconf/config/sample-plugin:sample-plugin/pg-streams" - -- {"id":"dns1", "is-enabled":"true"} shows the stream "dns1" is enabled. The packet generator sends requests in the rate of 100 packets per 10 seconds; + curl -X PUT -H "Authorization: Basic YWRtaW46YWRtaW4=" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -d '{"pg-streams":{"pg-stream": [{"id":"dns1", "is-enabled":"true"}]}}' "http://PacketGen_IP:8183/restconf/config/sample-plugin:sample-plugin/pg-streams" + +- {"id":"dns1", "is-enabled":"true"} shows the stream "dns1" is enabled. The packet generator sends requests in the rate of 100 packets per 10 seconds; - To increase the amount of traffic, you can enable more streams. The packet generator has 10 streams, "dns1", "dns2", "dns3" to "dns10". Each of them generates 100 packets per 10 seconds. To enable the streams, please add {"id":"dnsX", "is-enabled":"true"} to the pg-stream bracket of the curl command, where X is the stream ID. For example, if you want to enable 3 streams, the curl command will be: @@ -86,7 +86,7 @@ When the VNF starts, the packet generator is automatically configured to run 5 s Running the Use Case ~~~~~~~~~~~~~~~~~~~~ -Automated closed loop via Robot Framework is not supported at this time. For documentation about running the use case manually for previous releases, please look at the videos and the material available at this `wiki page`__. +Automated closed loop via Robot Framework is not supported at this time. For documentation about running the use case manually for previous releases, please look at the videos and the material available at this `wiki page`_. __ https://wiki.onap.org/display/DW/Running+the+ONAP+Demos @@ -102,4 +102,4 @@ Known issues and resolution b) The SDNC preload for the scaling VF module must set the VF module name to "vDNS\_xyz", where "xyz" is the same as the base module. This is required because during closed loop Policy looks for "Vfmodule\_" and replaces it with "vDNS\_" -3) Only one scaling operation is supported.
\ No newline at end of file +3) Only one scaling operation is supported. diff --git a/docs/index.rst b/docs/index.rst index 395213ef5..7b4d296b7 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -14,3 +14,4 @@ INTEGRATION integration-labs.rst integration-CICD.rst integration-tests.rst + integration-tooling.rst diff --git a/docs/integration-labs.rst b/docs/integration-labs.rst index 2ac8ffb14..fe6fc0f4f 100644 --- a/docs/integration-labs.rst +++ b/docs/integration-labs.rst @@ -43,7 +43,7 @@ have been stopped. For Guilin only SB-00 has been kept and re-installed for the use case support. If you want to use this lab, you need a VPN access. The procedure is described in -the `wiki <https://wiki.onap.org/pages/viewpage.action?pageId=29787070>`__. +the `wiki <https://wiki.onap.org/pages/viewpage.action?pageId=29787070>`_. Environment Installation Scripts ................................ @@ -72,5 +72,5 @@ i.e. Frankfurt release during Guilin development time. Please note that such labs do not provide admin rights and is shared with all the users. It can be used to discover ONAP. -See `Orange Openlab access procedure <https://wiki.onap.org/display/DW/Orange+OpenLab>`__ +See `Orange Openlab access procedure <https://wiki.onap.org/display/DW/Orange+OpenLab>`_ for details. diff --git a/docs/integration-missions.rst b/docs/integration-missions.rst index 331c92109..2cf0b474e 100644 --- a/docs/integration-missions.rst +++ b/docs/integration-missions.rst @@ -34,5 +34,5 @@ For each release, the integration team provides the following artifacts: and testing ONAP - Wiki release follow-up tables (blocking points, docker versions,...) -Please see the `integration wiki page <https://wiki.onap.org/display/DW/Integration+Project>`__ +Please see the `integration wiki page <https://wiki.onap.org/display/DW/Integration+Project>`_ for details. diff --git a/docs/integration-resources.rst b/docs/integration-resources.rst index 403ea9d71..a782fc990 100644 --- a/docs/integration-resources.rst +++ b/docs/integration-resources.rst @@ -48,7 +48,7 @@ The following information are available: It is possible to get results according to several criteria (version, case name, lab, period, last, CI id,..) -See the `OPNFV test API documentation <https://wiki.opnfv.org/pages/viewpage.action?pageId=2926452>`__. +See the `OPNFV test API documentation <https://wiki.opnfv.org/pages/viewpage.action?pageId=2926452>`_. Any company running ONAP Integration tests can be referenced to push their results to this database. diff --git a/docs/integration-tests.rst b/docs/integration-tests.rst index 52a8eb357..ece001f59 100644 --- a/docs/integration-tests.rst +++ b/docs/integration-tests.rst @@ -1,6 +1,6 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. integration-tests: +.. _integration-tests: Tests ===== @@ -28,7 +28,7 @@ Use Cases The use cases of the last release are described in :ref:`Verified Use cases <docs_usecases_release>`. -The history of the different use cases accross the different releases can be +The history of the different use cases across the different releases can be found in :ref:`Use Cases page <docs_usecases>`. CSIT Tests @@ -48,7 +48,7 @@ repository for 2 main reasons: In Guilin a PoC to help the project to re-insource their functional tests have been initiated. -See `CSIT wiki page <https://wiki.onap.org/display/DW/Maximizing+Benefits+of+CSIT+in+ONAP+Development>`__ +See `CSIT wiki page <https://wiki.onap.org/display/DW/Maximizing+Benefits+of+CSIT+in+ONAP+Development>`_ for details. Automatic Tests @@ -57,7 +57,7 @@ Automatic Tests These tests are run daily/weekly on each new gate (new patchset in OOM, clamp or SO). They can be in any language (bash, go, python,...), leveraging any test framework (robotframework, MTS, python-onapsdk). -They are all embedded in `xtesting <https://pypi.org/project/xtesting/>`__ dockers. +They are all embedded in `xtesting <https://pypi.org/project/xtesting/>`_ dockers. .. hint:: Automatic tests are currently divided in 4 different categories: @@ -89,7 +89,7 @@ Infrastructure Healthcheck Tests :delim: ; :header-rows: 1 -See `Infrastructure Healthcheck README <https://git.onap.org/integration/xtesting/tree/infra-healthcheck/README.md>`__ +See `Infrastructure Healthcheck README <https://git.onap.org/integration/xtesting/tree/infra-healthcheck/README.md>`_ to adapt then run infrastructure healthcheck tests on your own system. Please note that the onap-k8s is run 2 times in CD chains. It is run just after @@ -99,7 +99,7 @@ in order to collect the logs of the different components during the test executi .. figure:: files/tests/test-onap-k8s.png Healthcheck Tests -................ +................. .. csv-table:: Healthcheck Tests :file: ./files/csv/tests-healthcheck.csv @@ -107,7 +107,7 @@ Healthcheck Tests :delim: ; :header-rows: 1 -See `Healthcheck README <https://git.onap.org/integration/xtesting/tree/healthcheck/README.md>`__ +See `Healthcheck README <https://git.onap.org/integration/xtesting/tree/healthcheck/README.md>`_ to adapt then run healthcheck tests on your own system. Smoke Tests @@ -119,15 +119,15 @@ Smoke Tests :delim: ; :header-rows: 1 -See `Python smoke test README <https://git.onap.org/integration/xtesting/tree/smoke-usecases-robot/README.md>`__ +See `Python smoke test README <https://git.onap.org/integration/xtesting/tree/smoke-usecases-robot/README.md>`_ to adapt and run robot based smoke tests. An html page is generated by the pythonsdk-test tests. .. figure:: files/tests/test-basic-cnf.png -See `Robot smoke test README <https://git.onap.org/integration/xtesting/tree/smoke-usecases-pythonsdk/README.md>`__ -to adapt and run pythonsdk based smoke tests. +See `Robot smoke test README <https://git.onap.org/integration/xtesting/tree/smoke-usecases-pythonsdk/README.md>`_ +to adapt and run python-onapsdk based smoke tests. Standard Robot html pages are generated. See :ref:`Robot page <docs_robot>`. Security Tests @@ -139,11 +139,11 @@ Security Tests :delim: ; :header-rows: 1 -See `Security test README <https://git.onap.org/integration/xtesting/tree/security/README.md>`__ +See `Security test README <https://git.onap.org/integration/xtesting/tree/security/README.md>`_ to adapt then run the security tests on your own system. Note for security tests, integration team follows `SECCOM recommendations and -apply waivers granted by SECCOM if needed through xfail lists <https://git.onap.org/integration/seccom/tree/>`__. +apply waivers granted by SECCOM if needed through xfail lists <https://git.onap.org/integration/seccom/tree/>`_. Stability Testing ----------------- diff --git a/docs/integration-tooling.rst b/docs/integration-tooling.rst new file mode 100644 index 000000000..e69f99054 --- /dev/null +++ b/docs/integration-tooling.rst @@ -0,0 +1,185 @@ +.. This work is licensed under a + Creative Commons Attribution 4.0 International License. +.. integration-tooling: + +Tooling +======= + +.. important:: + Integration team deals with lots of tools to complete its missions. The goal + of this section is to highlight some of them and redirect to their official + documentation. These tools can be used for CI/CD, Testing or platform management. + + **Upstream tools** are priviledged but when needed specific developments can be done. + + Please note that none of these tools are imposed to test developers, in other + words, any kind of test is accepted and can be integrated, the list of tools + is just indicative. + +Testing +------- + +Test frameworks +~~~~~~~~~~~~~~~ + +Robotframework +.............. + +`robotframework <https://robotframework.org/>`_ is a well known test framework. +Lots of ONAP tests are leveraging this framework. +This framework is fully developed upstream even if some extensions (python +modules) were created especially to deal with OpenStack (see +`python-testing-utils project <https://git.onap.org/testsuite/python-testing-utils/>`_). + +Some GUI tests (using Robotframework Selenium extension) had been initiated but +not maintained, as a consequence there are not integrated in CI/CD. + + +Python-onapsdk +.............. + +The Openstack and Kubernetes python SDK are references widely adopted by the +developers and the industry. Developing a python ONAP SDK aimed to follow the +examples of the infrastructure SDK with the same expectations in term of code +quality. +After an evaluation of the CLI project (JAVA SDK re-exposing primitives through +python system calls), and a first prototype (onap_tests used until Frankfurt for +end to end tests) it was decided to develop a new python SDK. + +This SDK has been developed in gitlab.com to benefit from the numerous built-in +options offered by gitlab and ensure the best possible code quality. + +- `python SDK repositoy <https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk>`_ +- `python SDK documentation <https://python-onapsdk.readthedocs.io/en/latest/?badge=develop>`_ + +The project is fully Open Source, released under the Apache v2 license. +Integration committers are invited to join the project. The main maintainers are +ONAP integration and OOM committers. + +Any new feature shall respect the code quality criteria: + +- unit test coverage > 98% +- functional tests (several components mock objects have been developed) + +.. attention:: + Python-onapsdk is a **SDK**, it means it is a tool allowing to communicate + with ONAP. It is a **middleware** that can be used by test projects but it is + **NOT a test**. + +A compagnon project has been created in ONAP: +`pythonsdk-tests <https://git.onap.org/testsuite/pythonsdk-tests/>`_. + +The pythonsdk-test project defines tests based on python-onapsdk. + +The tests are hosted in this repository. They consume the different needed SDK: +python-onapsdk but also the kubernetes, the OpenStack SDK and or any needed +additional middlewares. +The project developed the notion of steps that can been combined and reorganized +as need to design a test. This project interacts with ONAP only through the +python-onapsdk library. +The tests are described in :ref:`The Integration Test page <integration-tests>`. + +The available steps are: + +- [CLAMP] OnboardClampStep: Onboard a SDC including a TCA blueprint +- [CDS] ExposeCDSBlueprintprocessorNodePortStep: expose CDS blueprint nodeport (Guilin workaround) +- [CDS] BootstrapBlueprintprocessor: Bootstrap a blueprint processor +- [CDS] DataDictionaryUploadStep: Upload a Data Dictionary to CDS +- [CDZ] CbaEnrichStep: Enrich CBA +- [K8S plugin] K8SProfileStep: Create K8S profile +- [SO] YamlTemplateVfModuleAlaCarteInstantiateStep: Instantiate VF module described in YAML using SO a'la carte method +- [SO] YamlTemplateVlAlaCarteInstantiateStep: Instantiate network link described in YAML using SO a'la carte method. +- [SO] YamlTemplateVfModuleAlaCarteInstantiateStep: Instantiate VF module described in YAML using SO a'la carte method +- [SO] YamlTemplateVnfAlaCarteInstantiateStep: Instantiate vnf described in YAML using SO a'la carte method +- [SO] YamlTemplateServiceAlaCarteInstantiateStep: Instantiate service described in YAML using SO a'la carte method +- [AAI] ConnectServiceSubToCloudRegionStep: Connect service subscription with cloud region +- [AAI] CustomerServiceSubscriptionCreateStep: Create customer's service subscription +- [AAI] CustomerCreateStep: Create customer +- [AAI] LinkCloudRegionToComplexStep: Connect cloud region with complex +- [AAI] ComplexCreateStep: Create complex +- [AAI] RegisterCloudRegionStep: Register cloud region +- [SDC] YamlTemplateServiceOnboardStep: Onboard service described in YAML file in SDC +- [SDC] YamlTemplateVfOnboardStep: Onboard vf described in YAML file in SDC +- [SDC] YamlTemplateVspOnboardStep: Onboard vsp described in YAML file in SDC +- [SDC] VendorOnboardStep: Onboard vendor in SDC + +You can reuse the existing steps to compose your test and/or code your own step +if it is not supported yet. + +The procedure to start a test is described in `pythonsdk-test README <https://git.onap.org/testsuite/pythonsdk-tests/tree/README.md>`_ + +Simulators +~~~~~~~~~~ + +Several simulators are created to support the use cases. + +.. important:: + Before starting the development of a new simulator, please consider the existing + ones, you may fine a simulator that already partially fulfills your needs.. + if so priviledge contributing to the simulator than creating a new one. + +pnf simulator +............. + +The `pnf-simulator <https://git.onap.org/integration/simulators/pnf-simulator/>`_ +can be used for several tasks: + +- Simulate PNF and interact with CDS (reconfiguration, template update) +- Send VES event to the VES collector and trigger closed loops + +A Rest API has been integrated in Guilin, allowing a http control interface of +the simulator. + +See 'README.md <https://gerrit.onap.org/r/gitweb?p=integration/simulators/pnf-simulator.git;a=blob_plain;f=pnfsimulator/README.md;hb=43d113d683ab082f8e2b7ce062e9601e74ffde3a>'__ +for details. + +Please note that this simulator has optional python CLI, see +'README.md <https://gerrit.onap.org/r/gitweb?p=integration/simulators/pnf-simulator.git;a=blob_plain;f=simulator-cli/README.md;hb=43d113d683ab082f8e2b7ce062e9601e74ffde3a>'__ +for details. + +.. note:: + There are several pnf-simulators. This simulator is a legacy simulator. It + was forked and one of the fork is known as Mass PNF simulator (hosted in + integration repository). + + +CI/CD +----- + +The CI/CD is key for integration. It consolidates the trustability in the solution +by the automated verification of the deployment and the execution of tests. +Integration tests complete the component tests (unit and functional known as +CSIT tests). + +Xtesting +~~~~~~~~ + +As the tests can be very heterogeneous (framework, language, outputs), the +integration team integrates the tests in simple isolated execution context based +on docker called **xtesting dockers**. + +Xtesting is a python library harmonizing the way to setup, run, teardown, +manage the artifacts, manage the reporting of the tests (automatic push of the +results on a DB backend). It was developed by +`OPNFV functest project <https://git.opnfv.org/functest-xtesting/>`_. +This python library is included in an alpine docker and contains the needed +tests, their associated libraries as well as a testcases.yaml listing these tests. +These docker files are built on any change in the integration/xtesting repository +and daily to take into account the upstream changes. + +The integration project manages 5 xtesting dockers, see +:ref:`Integration Test page <integration-tests>`. + +.. important:: + **xtesting is a CI/CD framework, neither a test nor a test framework** + + Testers can provide tests independently from xtesting. + However to be part of the CI/CD chains, an integration of the test in xtesting + will be required. + +The configuration files are provided as volumes and defined in each docker. +The use of this CI/CD abstraction for the tests simplify the integration +of the test suites in any CI/CD systems and harmonize the inputs and the outputs. + +The official documentation can be found on +`xtesting official web site <https://xtesting.readthedocs.io/en/latest/>`_ diff --git a/docs/release-notes.rst b/docs/release-notes.rst index edfe6d50e..604837915 100644 --- a/docs/release-notes.rst +++ b/docs/release-notes.rst @@ -12,7 +12,7 @@ Integration Release Notes :delim: ; :header-rows: 1 -.. highlight:: rst +.. important:: - New use cases (cmpv2, ves-collector) - New smoke tests based on pythonsdk-tests (replace onap_tests) |