diff options
Diffstat (limited to 'docs')
162 files changed, 7585 insertions, 3109 deletions
diff --git a/docs/_static/css/ribbon.css b/docs/_static/css/ribbon.css index 6008cb1a0..7949130b3 100644 --- a/docs/_static/css/ribbon.css +++ b/docs/_static/css/ribbon.css @@ -1,20 +1,20 @@ .ribbon { - z-index: 1000; - background-color: #a00; - overflow: hidden; - white-space: nowrap; - position: fixed; - top: 25px; - right: -50px; - -webkit-transform: rotate(45deg); - -moz-transform: rotate(45deg); - -ms-transform: rotate(45deg); - -o-transform: rotate(45deg); - transform: rotate(45deg); - -webkit-box-shadow: 0 0 10px #888; - -moz-box-shadow: 0 0 10px #888; - box-shadow: 0 0 10px #888; - + z-index: 1000; + background-color: #a00; + overflow: hidden; + white-space: nowrap; + position: fixed; + top: 25px; + right: -50px; + -webkit-transform: rotate(45deg); + -moz-transform: rotate(45deg); + -ms-transform: rotate(45deg); + -o-transform: rotate(45deg); + transform: rotate(45deg); + -webkit-box-shadow: 0 0 10px #888; + -moz-box-shadow: 0 0 10px #888; + box-shadow: 0 0 10px #888; + } .ribbon a { @@ -59,5 +59,5 @@ /* fix width of the screen */ .wy-nav-content { - max-width: none; + max-width: 800px; } diff --git a/docs/automated-usecases.csv b/docs/automated-usecases.csv deleted file mode 100644 index af8c34b82..000000000 --- a/docs/automated-usecases.csv +++ /dev/null @@ -1,7 +0,0 @@ -Use Case;Description;Test Framework -basic_vm;Onboard, distribute and instantiate a simple Ubuntu VM based on its heat template.;`onap-tests <https://gitlab.com/Orange-OpenSource/lfn/onap/onap-tests/-/blob/master/onap_tests/xtesting/basic_vm.py>`__ -clearwater_ims;Onboard, distribute and instantiate a clearwater vIMS (6 VMs).;`onap-tests <https://gitlab.com/Orange-OpenSource/lfn/onap/onap-tests/-/blob/master/onap_tests/xtesting/clearwater_ims.py>`__ -freeradius_nbi;Onboard, distribute and instantiate a simple VM including freeradius, the instantiation is realized through the external API module (not direct call to SO);`onap-tests <https://gitlab.com/Orange-OpenSource/lfn/onap/onap-tests/-/blob/master/onap_tests/xtesting/freeradius_nbi.py>`__ -hv-ves;Automation of 5G Realtime PM and High Volume Stream Data Collection;`robot <https://git.onap.org/testsuite/tree/robot/testsuites/hvves-ci.robot>`__ -5GBulkPm;Automation of 5G Bulk PM;`robot <https://git.onap.org/testsuite/tree/robot/testsuites/usecases/5gbulkpm.robot>`__ -pnf-registrate;Automation of 5G - PNF PnP;`robot <https://git.onap.org/testsuite/tree/robot/testsuites/pnf-registration.robot>`__ diff --git a/docs/conf.py b/docs/conf.py index 68ef33b1a..14f37ca67 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -1,24 +1,72 @@ -from docs_conf.conf import * +project = "onap" +release = "master" +version = "master" + +author = "Open Network Automation Platform" +# yamllint disable-line rule:line-length +copyright = "ONAP. Licensed under Creative Commons Attribution 4.0 International License" + +pygments_style = "sphinx" +html_theme = "sphinx_rtd_theme" +html_theme_options = { + "style_nav_header_background": "white", + "sticky_navigation": "False" } +html_logo = "_static/logo_onap_2017.png" +html_favicon = "_static/favicon.ico" +html_static_path = ["_static"] +html_show_sphinx = False + +extensions = [ + 'sphinx.ext.intersphinx', + 'sphinx.ext.graphviz', + 'sphinxcontrib.blockdiag', + 'sphinxcontrib.seqdiag', + 'sphinxcontrib.swaggerdoc', + 'sphinxcontrib.plantuml' +] + +# +# Map to 'latest' if this file is used in 'latest' (master) 'doc' branch. +# Change to {releasename} after you have created the new 'doc' branch. +# branch = 'latest' + +intersphinx_mapping = {} +doc_url = 'https://docs.onap.org/projects' master_doc = 'index' -linkcheck_ignore = [ - r'http://localhost:.*', - 'http://CONSUL_SERVER_UI:30270/ui/#/dc1/services', - r'https://.*h=frankfurt', - r'http.*frankfurt.*', - r'http.*simpledemo.onap.org.*', - r'http://ANY_K8S_IP.*', - 'http://so-monitoring:30224', - r'http://SINK_IP_ADDRESS:667.*', - r'http.*K8S_HOST:30227.*', - r'http.*K8S_NODE_IP.*' -] +exclude_patterns = ['.tox'] + +spelling_word_list_filename='spelling_wordlist.txt' +spelling_lang = "en_GB" +# +# Example: +# intersphinx_mapping['onap-aai-aai-common'] = ('{}/onap-aai-aai-common/en/%s'.format(doc_url) % branch, None) +# intersphinx_mapping = {} +intersphinx_mapping['onap-oom'] = ('{}/onap-oom/en/%s'.format(doc_url) % branch, None) +intersphinx_mapping['onap-cli'] = ('{}/onap-cli/en/%s'.format(doc_url) % branch, None) html_last_updated_fmt = '%d-%b-%y %H:%M' def setup(app): app.add_css_file("css/ribbon.css") + +linkcheck_ignore = [ + r'http://localhost:\d+/' + r'http://localhost:.*', + r'http://CONSUL_SERVER_UI:30270/ui/#/dc1/services', + r'https://.*h=frankfurt', + r'http.*frankfurt.*', + r'http.*simpledemo.onap.org.*', + r'http://ANY_K8S_IP.*', + r'http://so-monitoring:30224', + r'http://SINK_IP_ADDRESS:667.*', + r'http.*K8S_HOST:30227.*', + r'http.*K8S_NODE_IP.*', + r'http.*REPO_IP.*', + r'http://team.onap.eu', + r'https://tools.ietf.org/html/rfc8345' +] diff --git a/docs/conf.yaml b/docs/conf.yaml deleted file mode 100644 index ab5928131..000000000 --- a/docs/conf.yaml +++ /dev/null @@ -1,7 +0,0 @@ ---- -project_cfg: onap -project: onap - -# Change this to ReleaseBranchName to modify the header -default-version: latest -# diff --git a/docs/docs_5G_Bulk_PM.rst b/docs/docs_5G_Bulk_PM.rst index eebb4ecd3..7bdc06324 100644 --- a/docs/docs_5G_Bulk_PM.rst +++ b/docs/docs_5G_Bulk_PM.rst @@ -3,6 +3,8 @@ .. _docs_5g_bulk_pm: +:orphan: + 5G Bulk PM ---------- diff --git a/docs/docs_5G_Configuration_over_NETCONF.rst b/docs/docs_5G_Configuration_over_NETCONF.rst index 10bf740e4..d8701a655 100644 --- a/docs/docs_5G_Configuration_over_NETCONF.rst +++ b/docs/docs_5G_Configuration_over_NETCONF.rst @@ -3,6 +3,8 @@ .. _docs_5G_Configuration_over_NETCONF: +:orphan: + 5G - Configuration over NETCONF ------------------------------- @@ -22,7 +24,7 @@ This use case is intended to be applicable for 5G base stations and other nodes How to Use ~~~~~~~~~~ -Set up certificate in SDNC using <https://docs.onap.org/en/dublin/submodules/sdnc/oam.git/docs/cert_installation.html?highlight=SDNC> +Set up certificate in SDNC using <https://docs.onap.org/projects/onap-sdnc-oam/en/latest/cert_installation.html> As this usecase is extention of PnP PNF flow so run PnP usecase following running this usecase follow link <https://wiki.onap.org/display/DW/5G+-+PNF+Plug+and+Play> diff --git a/docs/docs_5G_NRM_Configuration.rst b/docs/docs_5G_NRM_Configuration.rst index ee76d1c3e..1deeb97e8 100644 --- a/docs/docs_5G_NRM_Configuration.rst +++ b/docs/docs_5G_NRM_Configuration.rst @@ -3,6 +3,8 @@ .. _docs_5G_NRM_Configuration: +:orphan: + 5G NRM (Network Resource Model) Configuration --------------------------------------------- @@ -13,7 +15,6 @@ Network Resource Model (NRM) configuration management allows service providers t Useful Links ============ `5G NRM Configuration in R6 Wiki Page <https://wiki.onap.org/display/DW/5G+Network+Resource+Model+%28NRM%29+Configuration+in+R6+Frankfurt>`_ -`3GPP TS 28541 <https://www.3gpp.org/DynaReport/28541.htm>`_ Current Status in Frankfurt ~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -38,4 +39,3 @@ Test Status and Plans To see information on the status of the test cases, please follow the link below: `5G NRM Configuration Test Status <https://wiki.onap.org/display/DW/5G+Network+Resource+Model+%28NRM%29+Configuration+in+R6+Frankfurt#id-5GNetworkResourceModel(NRM)ConfigurationinR6Frankfurt-TestStatus>`_ - diff --git a/docs/docs_5G_PNF_Software_Upgrade.rst b/docs/docs_5G_PNF_Software_Upgrade.rst index 6b8e5d2d6..a4d435b69 100644 --- a/docs/docs_5G_PNF_Software_Upgrade.rst +++ b/docs/docs_5G_PNF_Software_Upgrade.rst @@ -3,6 +3,7 @@ .. _docs_5g_pnf_software_upgrade: +:orphan: 5G PNF Software Upgrade ----------------------- @@ -26,15 +27,15 @@ PNF Software Upgrade Scenarios There are 3 PNF software upgrade scenarios supported in Frankfurt release: -* `Using direct Netconf/Yang interface with PNF <docs_5G_PNF_Software_Upgrade_direct_netconf_yang.html>`_ +* `Using direct Netconf/Yang interface with PNF <docs_5G_PNF_Software_Upgrade_direct_netconf_yang>` - (https://wiki.onap.org/pages/viewpage.action?pageId=64007309) -* `Using Ansible protocol with EM <docs_5G_PNF_Software_Upgrade_ansible_with_EM.html>`_ +* `Using Ansible protocol with EM <docs_5G_PNF_Software_Upgrade_ansible_with_EM>` - (https://wiki.onap.org/pages/viewpage.action?pageId=64007357) -* `Using Netconf/Yang interface with EM <docs_5G_PNF_Software_Upgrade_netconf_with_EM.html>`_ +* `Using Netconf/Yang interface with EM <docs_5G_PNF_Software_Upgrade_netconf_with_EM>` - (https://wiki.onap.org/pages/viewpage.action?pageId=64008675) diff --git a/docs/docs_5G_PNF_Software_Upgrade_With_Schema_Update.rst b/docs/docs_5G_PNF_Software_Upgrade_With_Schema_Update.rst new file mode 100644 index 000000000..c844f1f5d --- /dev/null +++ b/docs/docs_5G_PNF_Software_Upgrade_With_Schema_Update.rst @@ -0,0 +1,114 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +.. _docs_5g_pnf_software_upgrade_with_schema_update: + +:orphan: + +Support xNF Software Upgrade in association to schema updates +------------------------------------------------------------- + +Description +~~~~~~~~~~~ + +A schema update in relation to a xNF software upgrades is a routine for network upgrade to support new xNF features, improve efficiency or increase xNF capacity on the field, and to eliminate bugs. This use case provides to ONAP an advantage in orchestrating and managing the Life Cycle of a Network Services in-line with business and service objectives. Deployment and orchestration of new services over CNFs, VNFs and PNFs in a model and software driven way simplifies the network management. Enables operators and service providers to manage the Life Cycle of a Network Service. Assuring continuity of operation of services is crucial for production and carrier grade environments. The actualization or upgrades of software and in consequence required changes in the service model is a natural part of service instance life cycle. Without the support of ONAP service update with schema change, service life cycle management by ONAP can be very difficult which can impact the quality and continuity of services. + + +Current Status in Guilin +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +xNF Software Upgrade with xNF artifacts updating in Release G +------------------------------------------------------------- + +The following is the xNF software upgrade procedure with schema update. + +.. image:: files/softwareUpgrade/SchemaUpdate.png + +1. A vendor shall provide + a. a new VNF/PNF package with updated artifacts, and + b. the new VNF/ PNF software image to the operator. +2. At receiving of the new package, the operator shall + a. onboard the new package and create a new resource template or update the existing resource template (PNF or VNF) + b. update the existing service template with the new or updated resource template + c. distribute the updated service template to run time. +3. At run time, the operator shall, based on the updated service template, + a. upgrade a service instance and its resource instances, and + b. update the AAI entry accordingly + +The above procedure is based on the following conditions: + +* When updating a service template at design time, the resource instance name and network topology shall be unchanged. + +* A service template must be upgradable from any previous versions, including that any new resource template of a given resource instance (within the service template) must be upgradeable from any previous resource template versions. + +* At run time, resource upgrade sequence is not sensitive in service instance upgrading procedure. + +Function limitations in Release G +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* The operator shall know the possible/feasible resource upgrade path based on vendor provided information. + +* When operator updating a service template, the updated service template must be upgradable from any previous versions: + - Within the service template, the resource instance name and network topology are unchanged. + - The new resource template of a given resource instance (within the service template) must be upgradeable from any previous resource template versions. + +.. note:: + This is to avoid adding possible upgrade paths info and upgrade sequence info into SDC model + +Update a xNF resource template from a new onboarding package +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When updating a resource template from a new VSP casr, the new onboarded descriptor and the new onboarded artifacts will be transformed into the new version of the resource csar. The current resource name and invariantUUID will be remained. + +As an alternative, a resource csar can be updated manually using SDC GUI. + +.. image:: files/softwareUpgrade/OnboardingCsar.png + +The update path (green path in above picture) is supported in the current SDC implementation. However, there are bugs which need to be fixed. + +Service level LCM workflow in SO +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. image:: files/softwareUpgrade/ServiceLevelWorkflow.png + +A generic SO workflow is created which can be used to upgrade one service instance based on the updated service template. This service level workflow is network function type independent. When upgrade one resource instance, the subsequent resource level upgrade workflow is selected based on the network function type. It contains following main steps: + +* Service Level Preparation + - Creating resource template instance upgrade list by comparing the service templates + - Select a resource level health check workflow based on the resource type + - Execute the selected resource level health check workflow on all resource instances within the service +* Service Level Upgrade + - Select a resource level upgrade workflow based on the resource type + - Execute the selected resource level upgrade workflow on each upgrading resource instances + - Update the software version, model-invariant-id and model-version-id of the resource template in the A&AI entry at end of each Resource level upgrade workflow +* Service Level Update + - Update the model-version-id of the service template in the A&AI entry +* Service Level postCheck + - Select a resource level health check workflow based on the resource type + - Execute the selected resource level health check workflow on all resource instances within the service + +The following is an example of the service level workflow with PNF upgrade sub-workflow is called at Service Level Upgrade step: + +.. image:: files/softwareUpgrade/ServiceLevelUpgrade.png + +Workflow view +~~~~~~~~~~~~~ + +.. image:: files/softwareUpgrade/WorkflowView.png + +SO APIs +~~~~~~~ +.. csv-table:: use case table + :file: schema-update-apis.csv + :widths: 60,20,20 + :header-rows: 1 + +Reference +~~~~~~~~~~~ + +`PNF Software Upgrade with Schema Update Wiki Page <https://wiki.onap.org/pages/viewpage.action?pageId=81400388#SupportxNFSoftwareUpgradeinassociationtoschemaupdates-DevelopmentStatus>`_ + +Testing Procedure +~~~~~~~~~~~~~~~~~~ + +:ref:`Testing 5G PNF Software Upgrade with Schema Update <docs_Testing_5G_PNF_Software_Upgrade_With_Schema_Update>`
\ No newline at end of file diff --git a/docs/docs_5G_PNF_Software_Upgrade_ansible_with_EM.rst b/docs/docs_5G_PNF_Software_Upgrade_ansible_with_EM.rst index 1482cb5d6..6426446eb 100644 --- a/docs/docs_5G_PNF_Software_Upgrade_ansible_with_EM.rst +++ b/docs/docs_5G_PNF_Software_Upgrade_ansible_with_EM.rst @@ -3,6 +3,8 @@ .. _docs_5g_pnf_software_upgrade_ansible_with_EM: +:orphan: + PNF Software Upgrade Scenario: Using Ansible protocol with EM ------------------------------------------------------------- diff --git a/docs/docs_5G_PNF_Software_Upgrade_direct_netconf_yang.rst b/docs/docs_5G_PNF_Software_Upgrade_direct_netconf_yang.rst index f2d4db1a4..24098cdc4 100644 --- a/docs/docs_5G_PNF_Software_Upgrade_direct_netconf_yang.rst +++ b/docs/docs_5G_PNF_Software_Upgrade_direct_netconf_yang.rst @@ -3,11 +3,13 @@ .. _docs_5g_pnf_software_upgrade_direct_netconf_yang: -=========================================================================== +:orphan: + PNF Software Upgrade Scenario: Using Direct Netconf/Yang interface with PNF =========================================================================== + Software Upgrade Procedure ------------------------------------- +--------------------------- With this scenario, the pre-conditions are: @@ -28,9 +30,8 @@ c. Repeat above two steps for each SO building blocks. Test Status and Plans ------------------------------------- +--------------------- To see information on the status of the test cases please follow the link below: `PNF Software Upgrade Test Status <https://wiki.onap.org/display/DW/PNF+software+upgrade+in+R6+Frankfurt#PNFsoftwareupgradeinR6Frankfurt-TestStatus>`_ - diff --git a/docs/docs_5G_PNF_Software_Upgrade_netconf_with_EM.rst b/docs/docs_5G_PNF_Software_Upgrade_netconf_with_EM.rst index a42113c70..75eb244e1 100644 --- a/docs/docs_5G_PNF_Software_Upgrade_netconf_with_EM.rst +++ b/docs/docs_5G_PNF_Software_Upgrade_netconf_with_EM.rst @@ -3,6 +3,8 @@ .. _docs_5g_pnf_software_upgrade_netconf_with_EM: +:orphan: + PNF Software Upgrade Scenario: Using Netconf/Yang interface with EM ------------------------------------------------------------------- diff --git a/docs/docs_5G_oof_pci.rst b/docs/docs_5G_oof_pci.rst deleted file mode 100644 index 6c0a2608f..000000000 --- a/docs/docs_5G_oof_pci.rst +++ /dev/null @@ -1,129 +0,0 @@ -.. 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 - -(ANR) function (blacklisting a neighbor for handovers) in a 4G/5G network using the ONAP - -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 - - -In Frankfurt release, the following are the main enhancements: - -- Introduction of Control Loop Coordination functionality, wherein a second control loop execution is - denied by Policy component when another control loop is in progress. -- Introduction of adaptive SON, wherein a set of cells whose PCI values are fixed (i.e., cannot be changed - 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. - - - - 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. - - -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 -functionality of the RAN Simulator includes: - -- Generation of neighbor-list-update messages -- Generation of alarms for PCI collision/confusion and -- Generation of handover metrics for different neighbor pairs (for the ANR use case). - -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 - - -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. - -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://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/services/son-handler/installation.html - - -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. - - -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. -(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 - to check the existence of active Control Loops by Policy. This will be addressed in Guilin release, and tracked via - https://jira.onap.org/browse/POLICY-2581 and https://jira.onap.org/browse/POLICY-2583. -(c) For Adaptive SON, the functionality in SON-Handler and OOF is implemented, however the OOF functionality is not - fully tested (this was anyhow a stretch goal). Further, the DCAE-CL-RSP message is not sent by Policy in Frankfurt release. - This is tracked via https://jira.onap.org/browse/POLICY-2580 and shall be part of Guilin release. diff --git a/docs/docs_5G_oof_son.rst b/docs/docs_5G_oof_son.rst new file mode 100644 index 000000000..0ec539d76 --- /dev/null +++ b/docs/docs_5G_oof_son.rst @@ -0,0 +1,128 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 + International License. http://creativecommons.org/licenses/by/4.0 + +.. _docs_5G_oof_son: + +:orphan: + +5G-SON (earlier name was OOF-SON) +--------------------------------- + +Description +~~~~~~~~~~~ + +The 5G OOF-SON (earlier name was 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). + +The use case is a multi-release effort. This use case began with the implementation of PCI optimization in the Casablanca release. In the Dublin release, the SON-Handler MS was onboarded as a micro-service in DCAE. Enhancements were made to Policy and SDN-C components. + + +RAN Simulator +~~~~~~~~~~~~~ + +As part of this use case work, the SON Use Case team developed RAN-Sim, which is a RAN Simulator providing a simulated Radio Access Network (RAN) with a number of netconf servers simulating PNF elements representing gNodeBs. The functionality of the RAN Simulator includes: + +- Input of a sample topology of cells, with netconf servers (representing DUs) representing groups of cells +- Represenation of cell locations and cell neighbor relations +- Generation of neighbor-list-update messages +- Generation of alarms for PCI collision/confusion and +- Generation of handover metrics for different neighbor pairs (for the ANR use case). +- Implementation of an O1 interface termination for CU/DU NFs +- Implementation of an A1 interface termination with A1-Termination and RAN-App (new for Kohn release) + +All above functionality are enabled using a simple UI. + + +Frankfurt Release +~~~~~~~~~~~~~~~~~ + +In Frankfurt release, the following were the main enhancements: + +- Introduction of Control Loop Coordination functionality, wherein a second control loop execution is denied by Policy component when another control loop is in progress. +- Introduction of adaptive SON, wherein a set of cells whose PCI values are fixed (i.e., cannot be changed 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 <https://wiki.onap.org/display/DW/CM+Notification+Support+in+ONAP>`_ + + +Istanbul Release +~~~~~~~~~~~~~~~~~ + +In the Istanbul release, the following are the main enhancements: + +- Updates in FM reporting and fault handling to be in line with VES 7.2, 3GPP and smoother future alignment with O-RAN O1 +- Alignment with 3GPP NRM/O-RAN yang models for SON use case +- Use CPS for storing/retrieving RAN config data for this use case (was stretch goal, partially addressed) +- Configuration Management (CM) notifications over VES based on VES 7.2 (was stretch goal, partially addressed) + +The end-to-end setup for the use case requires a database which stores the cell related details of the RAN. This database is ConfigDB till we complete the transition to using CPS DB/TBDMT. The database 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 <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 Istanbul release work, progress was made towards the goal of transitioning from ConfigDB to CPS DB. CPS DB is fully based on yang models, and we have developed a modeling approach using two yang models: + +- Primary model: (e.g., ran-network). This is a modular sub-set of, and fully aligned with, ORAN/3GPP 28.541 NRM yang model. This aligns with device models and vendor models (base and extensions) + +- Secondary model: (e.g, cps-ran-schema-model) This model captures information which is not present in ORAN model, e.g., region-to-cell (CU) mapping, latitude/longitude of DU. This also has derived information for API/query efficiency, e.g., list of neighbor cells. This aligns with operator network model for use cases and applications. + + +Jakarta Release +~~~~~~~~~~~~~~~ + +The following are the enhancements in the Jakarta release: + +- Update of SDN-R netconf code to use the new O1 yang models +- Update of RAN-Sim to use the new O1 yang models + +In the Jakarta release, the SON Use Case work was impacted by the fact RAN-Sim needed enhancements to implement new features. We have made progress in the following areas in planning for future releases. + +- Convergence on the VES message formats to be used for FM/PM/CM +- Inclusion of A1 based actions for the end-to-end SON Use Case +- Enhancement of RAN-Sim to include abstraction of RAN App and A1 Termination which would process an A1 message and update of a CU/DU +- Planning for replacement of Honeycomb netconf engine (project is archived) + +Kohn Release +~~~~~~~~~~~~ + +We have introduced a new paradigm in the Kohn release and taken steps to harmonize with O-RAN SC and new approaches for ONAP Control Loops. The following are the enhancements in the Kohn release: + +- We introduced a new paradigm of marking the RAN action SON control flows as being O1-based or A1-based. The PCI control flow is now an O1-based flow which goes to SDN-R for netconf-based configurations over O1 interface to the CU/DU (simulated in RAN-Sim). The ANR control flow is now an A1-based flow which goes to SDN-R/A1-PMS to generate A1 Policy messages over the A1 interface to the xApp/Near-RT RIC (simulated in RAN-Sim). +- The formats of the Control Loop Message between SON Handler MS, Policy, and SDN-R have been updated. Policies in Policy Function have been updated. The PCI flow remains as an O1-based netconf action from SDN-R, while major changes were made for the ANR flow +- We have introduce a new A1-based SON action flow leveraging the use of A1-PMS in SDN-R and A1-Termination in RAN-Sim. We have harmonized ONAP and O-RAN SC work, and cross-linked ONAP JIRAs to use O-RAN SC projects. +- We have major changes for RAN-Sim. There is a new A1-Termination module as well as a new RAN-App module. The RAN-App module abstracts the function of an xApp in the Near-RT RIC. RAN-App processes the A1 policy message payload and sends a message to the RAN-Sim controller to make configuration changes in the RAN NF (CU or DU) in the RAN-Sim. + + +For more information, please see: + +- `5G-SON Kohn release wiki page <https://wiki.onap.org/pages/viewpage.action?pageId=149029149>`_. + +- `5G-SON Jakarta release wiki page <https://wiki.onap.org/display/DW/R10+5G+SON+use+case>`_. + +- `5G-OOF-SON Base wiki page <https://wiki.onap.org/display/DW/5G+-+OOF+%28ONAP+Optimization+Framework%29+and+PCI+%28Physical+Cell+ID%29+Optimization>`_. + +- `OOF-SON 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 5G-SON use case is implemented in the Rutgers University (Winlab) ONAP Wireless Lab (OWL). +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: + +- `Wiki Installation page <https://wiki.onap.org/display/DW/Demo+setup+steps+for+Frankfurt>`_ + + +Test Status and Plans +~~~~~~~~~~~~~~~~~~~~~ + +See `test plans <https://wiki.onap.org/display/DW/R11+5G+SON+Integration+Tests>`_ 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 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 to check the existence of active Control Loops by Policy. This will be addressed in Jakarta release, and tracked via https://jira.onap.org/browse/POLICY-2484 +(c) Honeycomb netconf server project has been archived. The plan is to migrate to netopeer. As an interim step, we have a new ran-app module which interacts with the ran-sim controller. diff --git a/docs/docs_5g_a1_adaptor.rst b/docs/docs_5g_a1_adaptor.rst deleted file mode 100644 index 18e165e65..000000000 --- a/docs/docs_5g_a1_adaptor.rst +++ /dev/null @@ -1,54 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 - International License. http://creativecommons.org/licenses/by/4.0 - -.. _docs_5g_a1_adaptor: - -5G - A1 Adaptor ---------------- - -Description -~~~~~~~~~~~ - -A1 is an O-RAN defined interface between Non-Real Time RIC (Ran Intelligent Controller) in the management platform (ONAP) and RAN network element called Near-Real Time RIC. -A1 interface is used to communicate policy choices, AI/ML model updates, and other RAN functions that are not included in the traditional network configuration. -O-RAN defines architecture of RT RIC and relevant interfaces. -O-RAN WG2 has released the first version of A1 specifications September 2019. -ONAP needed to implement a module serving a communication channel between other ONAP components and RT RIC for A1 interface. -ONAP community has a harmonization project with mobility standard and A1 adaptor has been proposed in the project (https://wiki.onap.org/display/DW/MOBILITY+STANDARDS+HARMONIZATION+WITH+ONAP). -A1 adaptor has been implemented as a component in CCSDK. All implementation details are explained here: https://wiki.onap.org/display/DW/A1+Adapter+in+ONAP - -How to Use -~~~~~~~~~~ - -Following steps describe a general procedure about how to use A1 adaptor. - -1. ONAP Frankfurt includes A1 adaptor. - -2. Edit A1 adaptor property file in sdnc container at dev-sdnc-x POD. (dev is an example of release name and x is replica number) - - a. A property file is located at /opt/onap/ccsdk/data/properties/a1-adapter-api-dg.properties. - - b. SSH into a rancher node (NFS/rancher). - - c. sudo su - - d. kubectl get pods -n onap -o wide | grep sdnc - - e. execute the following command to all sdnc PODs to update properties files. - - - kubectl exec -it dev-sdnc-x bash (x=0,1,2, depending on number of sdnc replicas in the setup) - - f. Once in the docker, edit the properties file. - - g. Make following configuration changes per setup - - - Update IP address and port number for Near-Real Time RIC as below - - - near-rt-ric-id=a.b.c.d:port - -A1 adaptor has been tested with A1 mediator as an example of Near-Real Time RIC. Detailed information can be found at its repo: https://gerrit.o-ran-sc.org/r/gitweb?p=ric-plt%2Fric-dep.git;a=shortlog;h=refs%2Fheads%2Fmaster. - -Test Status and Plans -~~~~~~~~~~~~~~~~~~~~~ - -For ONAP Frankfurt, A1 adaptor has not been involved in a full closed loop use case. A1 adaptor has gone through a unit test with A1 mediator in OSC as a underlying device. It has been tested for receiving A1 policy via DMaaP and publishing a response back to DMaaP as well as notification. More details are presented in https://wiki.onap.org/pages/viewpage.action?pageId=71837463. diff --git a/docs/docs_5g_pnf_pnp.rst b/docs/docs_5g_pnf_pnp.rst index c2fcc8548..7807062d8 100644 --- a/docs/docs_5g_pnf_pnp.rst +++ b/docs/docs_5g_pnf_pnp.rst @@ -3,14 +3,11 @@ .. _docs_5g_pnf_pnp: +:orphan: + 5G - PNF Plug and Play ---------------------- -Source files -~~~~~~~~~~~~ - -- Base PnP PNF Simulator docker compose file: https://gerrit.onap.org/r/gitweb?p=integration/simulators/pnf-simulator.git;a=blob_plain;f=pnfsimulator/docker-compose.yml;hb=refs/heads/master - Description ~~~~~~~~~~~ @@ -18,16 +15,66 @@ The PNF Plug and Play is a procedure that is executed between a PNF and ONAP. In **Useful Links** -- `5G - PNF Plug and Play use case documentation <https://wiki.onap.org/display/DW/5G+-+PNF+Plug+and+Play>`_ -- `5G - PNF Plug and Play - Integration Test Cases <https://wiki.onap.org/display/DW/5G+-+PNF+PnP+-+Integration+Test+Cases>`_ -- `Instruction how to setup and use PnP PNF Simulator <https://gerrit.onap.org/r/gitweb?p=integration/simulators/pnf-simulator.git;a=blob_plain;f=pnfsimulator/README.md;hb=refs/heads/master>`_ -- `PnP PNF Simulator git repository <https://gerrit.onap.org/r/gitweb?p=integration/simulators/pnf-simulator.git;a=summary>`_ +1. `5G - PNF Plug and Play use case documentation <https://wiki.onap.org/display/DW/5G+-+PNF+Plug+and+Play>`_ +2. `5G - PNF Plug and Play - Integration Test Cases <https://wiki.onap.org/display/DW/5G+-+PNF+PnP+-+Integration+Test+Cases>`_ +3. Instruction how to setup and use VES CLinet from :ref:`NF Simulator <nf_simulator>`. How to Use ~~~~~~~~~~ -1) Create and distribute service model which contains PNF -2) Create service for PNF and wait for PNF Ready message in DmaaP topic -3) Send PNF Registartion request from PnP PNF Simualtor and finish registration +1. Create and distribute service model which contains PNF +2. Create service for PNF and wait for PNF Ready message in DmaaP topic +3. Send PNF Registartion request from NF Simualtor (VES Client) and finish registration + +Below is present an example of event that need to be send to VES Client in order to trigger registration event from VES Client to ONAP VES Collector. +There is need to fill following values in example json with proper values: + +1. dcae-ves-collector-host-name +2. dcae-ves-collector-port +3. sourceName - Identifier of this Pnf information element. It is the first three letters of the Vendor and the PNF serial number. + This is a unique identifier for the PNF instance. It is also referred to as the Correlation ID. +4. oamV4IpAddress - This is the IP address (IPv4) for the PNF itself. This is the IPv4 address that the PNF itself can be accessed at. +5. oamV6IpAddress - This is the IP address (IPv6) for the PNF itself. This is the IPv6 address that the PNF itself can be accessed at. + +:: + + { + "vesServerUrl": "https://<dcae-ves-collector-host-name>:<dcae-ves-collector-port>/eventListener/v7", + "event": { + "event": { + "commonEventHeader": { + "startEpochMicrosec": 1538407540940, + "sourceId": "val13", + "eventId": "registration_38407540", + "nfcNamingCode": "oam", + "internalHeaderFields": {}, + "eventType": "pnfRegistration", + "priority": "Normal", + "version": "4.0.1", + "reportingEntityName": "VEN6061ZW3", + "sequence": 0, + "domain": "pnfRegistration", + "lastEpochMicrosec": 1538407540940, + "eventName": "pnfRegistration", + "vesEventListenerVersion": "7.0.1", + "sourceName": "<sourceName>", + "nfNamingCode": "gNB" + }, + "pnfRegistrationFields": { + "unitType": "val8", + "serialNumber": "6061ZW3", + "pnfRegistrationFieldsVersion": "2.0", + "manufactureDate": "1538407540942", + "modelNumber": "val6", + "lastServiceDate": "1538407540942", + "unitFamily": "BBU", + "vendorName": "VENDOR", + "oamV4IpAddress": "<oamV4IpAddress>, + "oamV6IpAddress": "<oamV6IpAddress>", + "softwareVersion": "val7" + } + } + } + } + -See <https://wiki.onap.org/display/DW/5G+-+PNF+PnP+-+Integration+Test+Cases>`_ for details. diff --git a/docs/docs_5g_rtpm.rst b/docs/docs_5g_rtpm.rst index eaed6786d..45f1103f2 100644 --- a/docs/docs_5g_rtpm.rst +++ b/docs/docs_5g_rtpm.rst @@ -3,6 +3,8 @@ .. _docs_realtime_pm: +:orphan: + 5G - Real Time PM and High Stream Data Collection ------------------------------------------------- @@ -18,8 +20,8 @@ The Real-Time Performance Measurements support allows for a PNF to send streamin Component and API descriptions can be found under: -- `High Volume VNF Event Streaming (HV-VES) Collector <https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/services/ves-hv/index.html>`_ -- `HV-VES (High Volume VES) <https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/apis/ves-hv/index.html#hv-ves-high-volume-ves>`_ +- `High Volume VNF Event Streaming (HV-VES) Collector <https://docs.onap.org/projects/onap-dcaegen2/en/frankfurt/sections/services/ves-hv/index.html>`_ +- `HV-VES (High Volume VES) <https://docs.onap.org/projects/onap-dcaegen2/en/frankfurt/sections/apis/ves-hv/index.html#hv-ves-high-volume-ves>`_ How to verify ~~~~~~~~~~~~~ diff --git a/docs/docs_BBS.rst b/docs/docs_BBS.rst index d2bca11c6..1047ae3d7 100644 --- a/docs/docs_BBS.rst +++ b/docs/docs_BBS.rst @@ -1,5 +1,7 @@ .. _docs_bbs: +:orphan: + BBS (Broadband Service) ----------------------- @@ -166,7 +168,7 @@ Create the required topics in DMaaP DCAE: BBS Event Processor (BBS-ep) ================================== -Description: :doc:`BBS-ep <https://docs.onap.org/en/frankfurt/submodules/dcaegen2.git/docs/sections/services/bbs-event-processor/>` +Description: `BBS-ep <https://docs.onap.org/projects/onap-dcaegen2/en/frankfurt/sections/services/bbs-event-processor/index.html?highlight=BBS>`_ The following BBS event processor blueprint will be used: @@ -191,7 +193,7 @@ IMPORTANT: Make sure that the configuration of BBS-ep in Consul contains the fol DCAE: RESTCONF Collector ======================== -Description: :doc:`RESTCONF Collector <https://docs.onap.org/en/frankfurt/submodules/dcaegen2.git/docs/sections/services/restconf/index.html>` +Description: `RESTCONF Collector <https://docs.onap.org/projects/onap-dcaegen2/en/frankfurt/sections/services/restconf/index.html>`_ The following RESTCONF collector blueprint will be used: @@ -209,7 +211,7 @@ RESTCONF Collector deployment procedure: DCAE: VES mapper ================ -Description: :doc:`VES Mapper <https://docs.onap.org/en/frankfurt/submodules/dcaegen2.git/docs/sections/services/mapper/>` +Description: `VES Mapper <https://docs.onap.org/projects/onap-dcaegen2/en/frankfurt/sections/services/mapper/index.html>`_ The following VES mapper blueprint will be used: diff --git a/docs/docs_CCVPN.rst b/docs/docs_CCVPN.rst index 11fb83525..d24862a68 100644 --- a/docs/docs_CCVPN.rst +++ b/docs/docs_CCVPN.rst @@ -3,22 +3,336 @@ .. _docs_ccvpn: +:orphan: + CCVPN (Cross Domain and Cross Layer VPN) ---------------------------------------- +Update for London Release +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The London release enhances the CCVPN use-case by introducing the Cloud-Network Convergence support (REQ-1413). +CCVPN London release will add transport domain support for the Intent-based cloud-network convergence. + +London Scope and Impacted modules +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The standardized cloud resource management APIs are still under our investigation. +In London, we will only support the registration of the Cloud Orchestrator to SNDC, +whose mechanism is similar to the network controller registration. + +The impacted ONAP modules are CCSDK and SDN-C. + +Installation Procedure +~~~~~~~~~~~~~~~~~~~~~~ + +For London's new features, the integration test environment is similar to that of +the Kohn release: an ONAP instance with London release interfacing with 3rd party +cloud orchestrators should be established. + +Functional/Integration Test Cases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The testing procedure is described in the following few test cases: +- Register a 3rd party cloud orchestrator to SDNC through ESR APIs +- Create and delete a single CLL instance that accesses a single cloud, and monitor if the closed-loop call flow is getting triggered. +- Modify the bandwidth of a connection link of an existing CLL instance, and monitor if the closed-loop call flow is getting triggered. + +Update for kohn Release +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The kohn release enhances the CCVPN use-case by introducing the following three features (REQ-1268): +1. E-LINE (P2P connection) support for the Cloud Leased Line (CLL) service delivery +2. Enhancing the Closed-Loop Automation of CCVPN services by using DCAE SDK dmaap-client lib in slice analysis MS +3. Enhancing TN NSSMF NBI to align with the latest IETF specification (SO changes) + +Kohn Scope and Impacted modules +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The Kohn release is an enhancement release. E-LINE service model (P2P connection) is added to the Cloud Leased Line (CLL) service. +Also, slice analysis MS is enhanced to use DCAE SDK dmaap-client lib. +And lastly, TN NSSMF northbound is aligned with the latest IETF transport slice definition model (SO changes). + +The impacted ONAP modules are: CCSDK, SDN-C, DCAE, and SO. + +Installation Procedure +~~~~~~~~~~~~~~~~~~~~~~ + +For Kohn new features, the integration test environment is similar to that of +the Jakarta release: an ONAP instance with Kohn release interfacing with 3rd party +transport domain controllers should be established. + +Functional/Integration Test Cases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The testing procedure is described in the following few test cases: +- Create and delete single CLL instance which accesses single cloud, and monitor if the closed-loop call flow is getting triggered. +- Modify the bandwidth of a connection link of an existing CLL instance, and monitor if the closed-loop call flow is getting triggered. + + +Update for Jakarta Release +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The Jakarta release enhances the CCVPN use-case by introducing the following three features (REG-1076): +1. Support for IBN service discovery by registering Cloud Leased Line (CLL) and Transport Slicing services to MSB +2. Support for 1+1 protection of Cloud Leased Line (CLL) +3. Support for closed-loop and user-triggered intent update + +Jakarta Scope and Impacted modules +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The "CCVPN closed-loop" feature and the "user-triggered intent update" feature require both a front-end and a back-end system. +The front-end would be different for IBN and CCVPN, but the two features can share a common back-end. +As a first step, current bandwidth usage of a CLL should be collected from the physical network. Then VES collector API +should be called to send this information to DCAE. DCAE would then publish a new DMaaP topic to be consumed by DCAE slice +analysis micro-service. This module will then send this notification to Policy. + +In Jakarta, the goal of both user-triggered intent update and CCVPN closed-loop is to ensure the max-bandwidth of the CLL service +can satisfy user's intent throughout the intent life cycle. Thus, the modify-CLL operation triggered by DCAE and Policy is +common to IBN and CCVPN. So a common back-end mechanism is implemented to support both use-cases. + +The impacted ONAP modules are: CCSDK, SDN-C, A&AI, DCAE, POLICY, and SO. + +Installation Procedure +~~~~~~~~~~~~~~~~~~~~~~ + +For Jakarta new features, the integration test environment is similar to that of +the Istanbul release: an ONAP instance with Istanbul release interfacing with 3rd party +transport domain controllers should be established. + +Functional/Integration Test Cases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The testing procedure is described in the following few test cases: +- Create and delete single CLL instance which accesses single cloud, and monitor if the closed-loop call flow is getting triggered. +- Create and delete single CLL instance which access multiple clouds, and monitor if the closed-loop call flow is getting triggered. +- Create and delete multiple CLL instances which access single cloud, and monitor if the closed-loop call flow is getting triggered. +- Create and delete multiple CLL instances which access multiple clouds, and monitor if the closed-loop call flow is getting triggered. +- Create a CLL instance which have connection links with different bandwidth, and monitor if the closed-loop call flow is getting triggered. +- Modify the bandwidth of a connection link of an existing CLL instance, and monitor if the closed-loop call flow is getting triggered. +- Modify an existing CLL instance by add a new connection link, and monitor if the closed-loop call flow is getting triggered. + + +Update for Istanbul Release +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The Istanbul release introduces a new functionality for the CCVPN use-case: +Cloud Lease Line (CLL) service support. The following three main operations were +added in Istanbul release (REQ-719): + +1. The support for creating an E-Tree service, which has one ROOT (Cloud POP) and may have + one or more LEAFs (i.e. ONUs) as its branches. +2. The support for modifying the maximum bandwidth supported by a given E-Tree. +3. The support for deleting an E-Tree service. + +Istanbul Scope and Impacted modules +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For operation #1 mentioned above, the user should be able to "create" an E-Tree service. +The modification operation is able to support the following scenarios: + +a. An E-Tree can have one or more branches (LEAFs) located in one or multiple (different) + domains. +b. When multiple LEAFs are physically located in a single OLT node, those LEAFs + should re-use or share the same OTN tunnels, therefore the path computation + mechanism should only be called once. + +By operation #2 mentioned above, a user can change/modify the maximum bandwidth supported +by a given E-Tree. + +And by operation #3 mentioned above, a user can delete a given E-Tree. + +The impacted ONAP modules are: SO, SDN-C, and A&AI. + +For A&AI, additional edge-rules were introduced between two connectivity nodes as well as +between a connectivity and a uni node. + +In SDN-C, additional Directed Graphs (DGs) were implemented to support the above-mentioned +features. These new DGs are placed under the generic-resource-api folder in SDNC. + +Installation Procedure +~~~~~~~~~~~~~~~~~~~~~~ + +For Istanbul new features, the integration test environment is similar to that of +the Honolulu release: an ONAP instance with Istanbul release interfacing with 3rd party +transport domain controllers should be established. + +For E-Tree support, 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 SO, ADNS, A&AI, and UUI. We also need to configure these modules along +with the mandatory common modules such as DMaaP. + +Functional/Integration Test Cases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The testing procedure is described in the following few test cases: + +- create an E-Tree with one ROOT and one or multiple LEAF(s) in a multi-domain topology +- modify the maximum bw of a given E-Tree or add a new connection link to a given E-Tree +- delete a given E-Tree + +To run such test cases, the user must first add (register) the domain controllers as the ESR +3rd party controllers. As a result of this registration, a round of topology discovery gets +triggered. After that, network-routes or UNI Endpoints have to be created in A&AI. This step +is similar to that of Guilin release, and is described in the following link: +https://wiki.onap.org/display/DW/Transport+Slicing+Configuration+and+Operation+Guidance + +Then an E-Tree creation, modification and deletion can be triggered from SO APIs. + + + +Update for Honolulu Release +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The Honolulu release continued to support and extend the Transport Slicing functionality +developed in Guilin release. Two main features were aded in Honolulu release (REQ-456): + +1. The support for reuse and modification of an existing TN NSSI has been developed. +2. In addition, the Honolulu release also continuted to support and extend the CCVPN + use-case and in particular, the support for inter-domain connections of three or + more network domains has been introduced in Honolulu release. (CCVPN in previous + releases were only be able to connect two domains). + +Honolulu Scope and Impacted modules +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For feature #1 mentioned above, the user should be able to "modify" a Transport Slice. +The modification operation is able to support the following three scenarios: + +a. A user may "Add" one or more new service(s)/connections link(s) to a given slice + (TN NSSI) that is already created. +b. A user may need to change or modify the maximum bandwidth attribute (i.e. the SLA + agreement) using which a given slice is created. +c. Both of the above operations. + +For feature #2 mentioned above, now in H release, we can have and support an artibrary +number of domains inter-connected to each other and we can support a cross-layer +cross-domain VPN connectivity and transport slicing for these kinds of scenarios as well. + +Impacted ONAP modules include: SO, SDN-C, CCSDK, A&AI. + +In CCSDk, a path computation engine (PCE) mechanism is introduced to support a +graph-based path computation in a multi-domain network topologies. This PCE system is +implemented as a SLI plugin to be called and used by Directed Graphs (DGs). + +For A&AI, additional attributes were introduced to the connectivity node and vpn-binding node. + +In SDN-C, additional Directed Graphs (DGs) were implemented to support the above-mentioned +two features. + +Installation Procedure +~~~~~~~~~~~~~~~~~~~~~~ + +For Honolulu new features, the integration test environment is similar to that of the Guilin +release: an ONAP instance with Honolulu release interfacing to 3rd party transport domain +controllers should be established. + +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. + +Functional/Integration Test Cases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The testing procedure is described in the following few test cases: + +- service/template design: Successful design of TN NSST and Slice Profile +- modify max-bandwidth of existing TN NSSI: Modify the maximum bandwidth of an existing TN NSSI +- modify connection links existing TN NSSI: Add new connection links to existing TN NSSI +- modify both max-bandwidth and connection links of TN NSSI: Modify both the maximum bandwidth and add new connection links to an existing TN NSSI +- three-domain network: Test create TN NSSI (or other NSI life cycle operations) on a three-domain network (i.e., need 3 ACTN PNC simulators) + + + +Update for Guilin Release +~~~~~~~~~~~~~~~~~~~~~~~~~ + +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. + +Guilin Scope and Impacted modules +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +MDONS Extension implementation for the Frankfurt release will incorporate the following: + +- Support Asynchronous OpenRoadM OTN service activation notification handling +- Add OOF support for inter domain link/path selection +- 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>`_ + +Transport Slicing in Guilin release has implemented the following TN NSSMF functionality: + +- Allocate TN NSSI +- Deallocate TN NSSI +- Activate TN NSSI +- Deactivate TN NSSI + +The Tranport Slicing implementation has made code changes in the following modules: + +- AAI (Schema changes only) +- UUI +- SO +- OOF +- SDN-C +- CCSDK +- Modelling + +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: + +- `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 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 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 Procedures +~~~~~~~~~~~~~~~~~~ + +The testing procedure is described in: + +- `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 @@ -26,6 +340,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. @@ -33,10 +348,8 @@ 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 +Usecase specific developments have been realized in SO, OOF, AAI, SDNC and UUI ONAP components.. Testing Procedure ~~~~~~~~~~~~~~~~~ @@ -44,22 +357,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 Domain 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 @@ -67,23 +382,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 ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -91,11 +415,14 @@ Update for Dublin release 1. Service model optimization 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 +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 + +See the `Details of Targeted Service Template wiki page <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. @@ -103,52 +430,69 @@ 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>`_ +- `CCVPN Test Status wiki page <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 `CCVPN Test Guide wiki page <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 @@ -189,7 +533,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 @@ -208,9 +552,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). @@ -228,6 +572,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_CM_flexible_designer_orchestrator.rst b/docs/docs_CM_flexible_designer_orchestrator.rst index 3a9dd7bfe..c919ec6f8 100644 --- a/docs/docs_CM_flexible_designer_orchestrator.rst +++ b/docs/docs_CM_flexible_designer_orchestrator.rst @@ -3,8 +3,10 @@ .. _docs_CM_flexible_designer_orchestrator: +:orphan: + Dublin Workflow Designer Release Notes -------------------------------------------------------------- +-------------------------------------- The Workflow Editor was developed in the Beijing release by Amdocs and is available in SDC for users to create workflows. @@ -287,4 +289,4 @@ part of the Dublin release. The others were not part of the release but are available to test with your vNF. Please refer to the Scale out release notes for further information. -https://onap.readthedocs.io/en/latest/submodules/integration.git/docs/docs_scaleout.html#docs-scaleout +https://docs.onap.org/projects/onap-integration/en/frankfurt/docs_scaleout.html diff --git a/docs/docs_CM_schedule_optimizer.rst b/docs/docs_CM_schedule_optimizer.rst index 9da2e5337..2ff8cfca1 100644 --- a/docs/docs_CM_schedule_optimizer.rst +++ b/docs/docs_CM_schedule_optimizer.rst @@ -1,15 +1,22 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. http://creativecommons.org/licenses/by/4.0 - -.. _docs_CM_schedule_optimizer: -Change Management Schedule Optimization -------------------------------------------------------------- +.. _docs_CM_schedule_optimizer: -Description +:orphan: + +Change Management Schedule Optimization +--------------------------------------- + +Description ~~~~~~~~~~~~~~ -The change management schedule optimizer automatically identifies a conflict-free schedule for executing changes across multiple network function instances. It takes into account constraints such as concurrency limits (how many instances can be executed simultaneously), time preferences (e.g., night time maintenance windows with low traffic volumes) and applies optimization techniques to generate schedules. +The change management schedule optimizer automatically identifies a conflict-free +schedule for executing changes across multiple network function instances. +It takes into account constraints such as concurrency limits (how many instances +can be executed simultaneously), time preferences (e.g., night time maintenance +windows with low traffic volumes) and applies optimization techniques to +generate schedules. -More details can be found here: -https://onap.readthedocs.io/en/latest/submodules/optf/cmso.git/docs/index.html
\ No newline at end of file +More details can be found here: +https://docs.onap.org/projects/onap-optf-cmso/en/latest/index.html#master-index diff --git a/docs/docs_E2E_network_slicing.rst b/docs/docs_E2E_network_slicing.rst index e177f8d8b..3686b2d0c 100644 --- a/docs/docs_E2E_network_slicing.rst +++ b/docs/docs_E2E_network_slicing.rst @@ -1,6 +1,8 @@ .. 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 +:orphan: + .. contents:: :depth: 3 .. @@ -12,9 +14,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 @@ -50,12 +51,58 @@ This use case is a multi-release 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. +This use case shall also collaborate with SDOs such as +O-RAN and ETSI to enable wider adoption and use. + +Architecture Choice +------------------- +3GPP(TS 28.801) defines three layer slice management functions which include: + +CSMF(Communication Service Management Function): + +• Responsible for translating the communication service related requirement to network slice related requirements. + +• Communicate with Network Slice Management Function (NSMF). + +NSMF(Network Slice Management Function): + +• Responsible for management and orchestration of NSI. +• Derive network slice subnet related requirements from network slice related requirements. +• Communicate with the Network Slice Subnet Management Function (NSSMF) and Communication Service Management Function. -Further details can be obtained from: -https://wiki.onap.org/display/DW/Use+Case+Description+and+Blueprint +NSSMF(Network Slice Subnet Management Function): +• Responsible for management and orchestration of NSSI. +• Communicate with the NSMF. + +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: + +1) Implement CSMF, NSMF, NSSMF all within ONAP; + +2) Connect an external CSMF from the Northbound, Implement NSMF and NSSMF within ONAP; + +3) Connect an external CSMF from the Northbound, Implement NSMF within ONAP, Connect a 3rd party NSSMF from the Southbound; + +4) Implement CSMF, NSMF within ONAP, Connect a 3rd party NSSMF from then Southbound. + +5) Use external CSMF and NSMF, only implement NSSMF within ONAP. + +External Interfaces +------------------- +The guiding principle is when a Slice Management function is outside ONAP, standard interfaces/APIs (3GPP, IETF, ETSI, TM Forum, etc.) can be supported by default, while any customization of such interfaces shall also be supported by ONAP using suitable plug-ins/adaptors. This would enable easier interoperability of slice management functions realized within ONAP with 3rd party slice management functions, as well as northbound and southbound systems. + +Another key point would be that both internal and external interface mechanisms should be supported by the corresponding ONAP modules. To be more specific, communication between Slice Management Functions within ONAP (e.g., CSMF and NSMF) shall use ONAP internal mechanisms such as workflow calls, DMaaPmessages, etc. or standard APIs as appropriate. For example, SO acting as NSMF should support API call directly from CSMF in ONAP, as well as API trigger from an external CSMF via EXT-API. + +Network Slice Instance (NSI) Life Cycle View +-------------------------------------------- +3GPP Specification (3GPP TS 28.530) describes management aspects of a Network Slice Instance, which can be described by the four phases: + +- Preparation: The preparation phase includes network slice design, network slice capacity planning, on-boarding and evaluation of the network functions, preparing the network environment and other necessary preparations required to be done before the creation of an NSI. +- Commissioning: NSI provisioning in the commissioning phase includes creation of the NSI. During NSI creation all needed resources are allocated and configured to satisfy the network slice requirements. The creation of an NSI can include creation and/or modification of the NSI constituents. +- Operation: The Operation phase includes the activation, supervision, performance reporting (e.g. for KPI monitoring), resource capacity planning, modification and de-activation of an NSI. +- Decommissioning: Network slice instance provisioning in the decommissioning phase includes decommissioning of non-shared constituents if required and removing the NSI specific configuration from the shared constituents. After the decommissioning phase, the NSI is terminated and does not exist anymore. + +The ONAP-based NSI lifecycle management will finally provide the demonstration of all these phases. Abbreviations ------------- @@ -83,246 +130,509 @@ Abbreviations +---------------+--------------------------------------------+ -Scope for Frankfurt -------------------- +Recap of Frankfurt functionality +-------------------------------- +In Frankfurt release, CSMF and NSMF within ONAP was implemented, while connecting to an external Core NSSMF. +From the NSI Life Cycle perspective, the scope for Frankfurt included NSI design and pre-provision, NSI instantiation +and configuration, and NSI activation and deactivation. In particular: -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. - -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: - -- CSMF: Functions of slice service creation, slice service activation and deactivation are implemented. - -- NSMF: Functions of NSI instantiation, NSI activation and deactivation are - implemented. In addition, manual intervention is also provided in NSMF slice task - management portal to ensure the selected NSI/NSSI as well as ServiceProfile and - SliceProfile are fine or need adjustment. - -- Design of CST, NST and onboarding NSST that are required to support the run-time orchestration functions is also provided. - -- To connect to the external (core) NSSMF, an adaptor is implemented to provide - interface between ONAP and 3rd party core NSSMF. - -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 - - -Impacted Modules for Frankfurt ------------------------------- - -SO -~~ - -CSMF and NSMF are implemented using SO BPMN workflows to support 5G -network slicing use case. CSMF workflow will process the user input -(service request) that comes from CSMF portal (UUI) and save the order -information into a communication service instance in AAI. Then CSMF will -send network slice request to NSMF workflow, and NSMF will then create -service profile, NSI and NSSI. Service profile is a logical concept -which exists only in AAI - it contains two AAI instances, one is a -profile instance that will hold the slice parameters, and the other is a -service instance which will be used to organize the NSI. NSI is also a -service instance in AAI which will be used to organize NSSI. NSSI is the -actual entity which will be created by NSSMF and an AAI service instance -will also be created to represent NSSI in ONAP context. NSI and NSSI can -both be shared. - -SO queries OOF for slice template selection and then slice instance -selection. In response to slice instance selection query, OOF may return -an existing slice instance or may recommend SO to create a new slice -instance. A new process called Orchestration Task is created to manage -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 - -U-UI -~~~~ - -Usecase-UI (UUI) has added CSMF and NSMF portal components to ONAP to -support this use case. - -CSMF component includes the functions of creating network slicing, as -well as displaying and processing all the created network slices. The -customers need to fill the create communication service form to create a -network slice and then they can see the created network slice in the -list and execute operations of activating, deactivating or terminating -the network slice. - -NSMF component mainly includes two modules: slicing task management and -slice resource management which provides the functions of displaying and -processing all the slicing tasks and slice resources. In slicing task -management module, network operators can find all the slicing tasks -created by customers in CSMF component and executing proper operations -according to different task status. In slice resource management module, -there are three sub-modules which provide the functions of displaying -and processing the existing NS, NSI and NSSI. In addition, the NSMF -component provides the monitoring function so that users can check the -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 - -OOF -~~~ - -For this use case OOF introduced two APIs which are used by SO, one for -slice template selection, and another for NSI/NSSI selection. Within -OOF, both the OSDF and HAS sub-components were enhanced for this use -case. OSDF maps the new API request contents to the appropriate format -for HAS to perform the optimization. After the optimization is done by -HAS, OSDF maps the response in the API response format as expected by -SO. Further, HAS always returns NSSI info (when existing NSSIs can be -reused) and OSDF then determines whether it refers to reuse of an -existing NSI or creation of a new NSI, and then prepares sends the -response to SO. - -HAS sub-component of OOF has been enhanced to use a couple of new policy -types, the AAI plug-in within HAS was enhanced to fetch the slice and -slice sub-net related details from AAI. Two new plug-ins were developed -in HAS – one for fetching slice templates and another for generating -slice profile candidates. Existing policies were reused and suitably -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 - -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 CSMF Portal in UUI captures the values for the requested -serviceCharacteristics that are required as inputs to CST Service model. -The relatedParty attribute in the Service Order is set according to the -Customer, where relatedParty.id will map to the AAI "global-customer-id“ -in the “customer” object. The serviceSpecification.id is to be set to -the UUID of the CST from SDC (i.e., this is the template for the Service -we are ordering from CSMF). The action field will be set to “add” to -indicate creation of a new service instance. CSMF Portal in UUI then -sends POST with the JSON body to /{api_url}/nbi/api/v4/serviceOrder/. -ExtAPI will generate a Service Order ID and send it in the response – -this ID can be used to track the order. ExtAPI will then invoke SO’s API -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 - -A&AI -~~~~ - -To support this use case，A&AI module has added 3 new nodes -(Communication-service-profile, Service-profile and -Slice-profile)，modified service-instance nodes, added 3 new nodes as -new attributes of service-instance node. To map to SDC templates -(Communication Service Template/Service Profile -Template/NST/NSST)，run-time instances of this use case have -Communication Service Instance/Service Profile Instance/NSI/NSSI. To -align with ONAP’s model-driven approach, this use case reuses -"service-instance" for all run-time instances. The relationship between -service-instances use the existing attribute "relationship-list" or -"allotted-resources". Communication-service-profile means the original -requirement of Communication-service-instance, such as latency, -data-rate, mobility-level and so on. Service-profile means the slice -parameter info of Service-profile-instance. Slice-profile holds the -slice sub-net parameter info of different network domain NSSIs, such as -(Radio) Access Network (AN), Transport Network (TN) and Core Network -(CN) NSSI. - -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. - -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 +- CSMF: Functions of slice service creation, slice service activation and deactivation were implemented. +- NSMF: Functions of NSI instantiation, NSI activation and deactivation were implemented. In addition, manual + intervention is also provided in NSMF slice task management portal to ensure the selected NSI/NSSI as well as + Service Profile and Slice Profile are OK or need adjustment. -Functional Test Cases ---------------------- +- Design of CST, NST and onboarding NSST that are required to support the run-time orchestration functions + +- To connect to the external (core) NSSMF, an adaptor was implemented to provide interface between ONAP and 3rd party + core NSSMF. + +To support the above functions, code impacts in U-UI, SO, OOF and ExtAPI components, and schema change in A&AI +were implemented. See the `Proposed Functions for R6 and Impacted Modules wiki page <https://wiki.onap.org/display/DW/Proposed+Functions+for+R6+and+Impacted+Modules>`_ for details. + +As part of Frankfurt release work, we supported the minimum-scope installation of ONAP to reduce the resource requirements. +From the module perspective, 5G E2E Slicing use case involves SDC, SO, A&AI, UUI, EXT-API, OOF and Policy modules of ONAP. +So we will configure these required modules along with the mandatory common modules such as DMaaP. Further, for each module, +the use case also does not use all of the charts，so we removed the not needed Charts under those modules to optimize the +resources required for setting up the use case. This approach will help to install a minimum-scope version ONAP for the +E2E Slicing use case. + +Further details of the installation steps are available at: `Install Minimum Scope ONAP for 5G Network Slicing wiki page +<https://wiki.onap.org/display/DW/Install+Minimum+Scope+ONAP+for+5G+Network+Slicing>`_ + +Recap of Guilin functionality +----------------------------- +From the architecture point of view, in Guilin release, besides the continuation of NSMF which was implemented in +Frankfurt release, the RAN NSSMF, TN NSSMF, CORE NSSMF have been implemented within ONAP, apart from interacting with +external RAN NSSMF and external CORE NSSMF. + +The following provides an overview of the enhancements done in Guilin release: + +- **Enhancements in NSMF**: Service Profile decomposition into Slice Profiles for 3 domains, NSI selection enhancement, + E2E slice instance creation including RAN, TN and CN slice sub-net instance creation/reuse, activation/deactivation + of E2E slice, and deciding whether to terminate E2E slice or not. + +- **RAN NSSMF, TN NSSMF, CN NSSMF within ONAP**: Basic logic for all 3 NSSMFs to support NSSI allocation, activation, + deactivation, deletion and modification (in case of reuse of NSSI). + +- **Enable NSMF interaction with RAN NSSMF, TN NSSMF, CN NSSMF**: Implement generic NSSMF adaptor for three domain NSSMFs, + alignment with standard interfaces (3GPP, IETF), enable the connection to external RAN NSSMF. -The functional testing of this use case shall cover creation and -activation of a service with an E2E Network Slice Instance which -contains a Core Slice Sub-net instance. It also addresses the -termination of an E2E Network Slice Instance. It covers the following -aspects: +- **Design of RAN NSST, TN NSST, CN NSST and Slice Profiles, TN information models**: Basic E2E Slicing model was provided + all the related templates designed from SDC, TN related information models. -- Creation of a new customer service via CSMF portal in UUI resulting - in creation of a new NSI +- **TMF 641 support**: Extension of the TMF 641 based interface from NB of ExtAPI to support service activation, + deactivation and termination. -- Creation of a new customer service via CSMF portal in UUI resulting - in re-use of an existing NSI +- **RAN and CN NFs set up and initial configurations**: CN NF simulators was developed: AMF, SMF, UPF and configure the + S-NSSAI on CN NFs; RAN NF Simulator was enhanced for PM data reporting, CU and Near-RT RIC configuration. -- Activation of a customer service via CSMF portal in UUI +- **KPI monitoring**: Implementation to request details of a KPI via UUI to ONAP DCAE. Providing the requested data to UUI + by DCAE using a new microservice (Data Exposure Service - DES). Enhancements in PM-Mapper to do KPI computation is + in progress, and will be completed in Honolulu release. -- Creation of a new customer service via postman request to EXT-API - resulting in creation of a new NSI +- **Closed Loop**: First steps to realizing a simple Closed Loop in the RAN using PM data collected from the RAN was + implemented - update the allowed throughput for a S-NSSAI per Near-RT RIC coverage area based on DL/UL PRB for data + traffic that was reported from the RAN. The analysis of the PM data was done using a new Slice Analysis MS in DCAE, + and the Policy-based Control Loop framework was applied to trigger the updates in the RAN. -- Creation of a new customer service via via postman request to ExtAPI - resulting in re-use of an existing NSI +- **Intelligent Slicing**: First steps to realizing a simple ML-based Closed Loop action in the RAN using PM data collected + from the RAN was implemented - update the maxNumberofConns for a S-NSSAI in each cell based on PDU session related + PM data that was reported from the RAN (PDU sessions requested, successfully setup and failed to be set up). The + training was done offline, and the ML model is onboarded as a micro-service to ONAP for demo purpose alone (it is + not part of ONAP code/repos). The ML model provides updates to the Slice Analysis MS, which then uses the + Policy-based Control Loop framework to trigger the updates in the RAN. -- Manual intervention via NSMF portal during NSI selection (NSI - selection adjustment) +- **Modeling enhancements**: Necessary modeling enhancements to support all the above functionalities. -- Termination of a NSI and associated NSSI +The base use case page for Guilin release is `E2E Network Slicing Use Case in R7 Guilin <https://wiki.onap.org/display/DW/E2E+Network+Slicing+Use+Case+in+R7+Guilin>`_. -- Interaction between ONAP and external NSSMF for new core NSSI - creation +The child wiki pages of the above page contains details of the assumptions, flows and other relevant details. -- Checking inventory updates in AAI for NSIs, service and slice - profiles and NSSIs. +Honolulu release updates +------------------------ +In Honolulu release, the following aspects were realized: -Further details can be obtained from: -https://wiki.onap.org/display/DW/Functional+Test+Cases +- **Modeling Enhancements** were made, details can be found at: + `Modeling enhancements in Honolulu <https://wiki.onap.org/display/DW/Modeling+enhancements+in+Honolulu>`_. + +- **Functional Enhancements** + + (a) Minor enhancements in NSMF and NSSMFs including NST Selection, Shared slices, coverageArea to + coverageAreaTAList mapping, etc. + (b) Enhancements related to endpoints for stitching together an end-to-end network slice + (c) Use of CPS (instead of Config DB) to determine the list of Tracking Areas corresponding to a given + Coverage Area (input by user). For the remaining RAN configuration data, we continue to use Config DB. + (d) RRM Policy update by SDN-R to RAN NFs during RAN NSSI creation/reuse + +- **Integration Testing** + Continuing with integration tests deferred in Guilin release, and associated bug-fixing + +Important Remarks +~~~~~~~~~~~~~~~~~~~ +(a) 2 deployment scenarios for RAN NSSI are supported. In the first scenario, the RAN NSSI comprises also of + TN Fronthaul (FH) and TN Midhaul (FH) NSSIs, and RAN NSSMF shall trigger TN NSSMF for TN FH and MH NSSI + related actions. In the second scenario, the RAN NSSI comprises only of RAN NFs. TN NSSMF shall be triggered by + NSMF for TN FH and MH NSSI related actions. This part is not yet implemented in NSMF within ONAP. + +(b) Details of the modeling aspects, flows and other relevant info about the use case are available in: + `R8 E2E Network Slicing Use Case <https://wiki.onap.org/display/DW/R8+E2E+Network+Slicing+use+case>`_ and its child wiki pages. + + +Impacted Modules for Honolulu +----------------------------- +The code-impacted modules of E2E Network Slicing in Honolulu release are: + +- **UUI**: The enhancements done include: + + (a) The coverageArea The coverageArea number param is added in CSMF creation UI. Users could input + the grid numbers to specify the area where they want the slicing service to cover. + (b) The relation link image of AN/TN/CN has been added. Users can see the links and related params + of the three domains. + (c) The TN’s connection link with AN/CN has been added in NS Task management GUI. + +- **AAI**: Schema changes were introduced. We added some new parameters in 2 nodes: + + (a) ‘Connectivity’ is used to store IETF/ACTN ETH service parameters. New attributes added in order + to support the CCVPN network configuration operations on multi-domain (2+) interconnections. + (b) ‘Vpn-binding’is used to store ACTN OTN Tunnel model’s parameters. + +- **OOF**: Updates include: + + (a) NST selection is enhanced by fetching the templates from SDC directly. + (b) coverageArea to coverageAreaTAList mapping is done by OOF (as part of Slice Profile generation) + by accessing CPS. + (c) Bug-fixes + +- **SO**: Main updates include support of NSI shared scenarios by enhancing the interaction with OOF, AAI and + UUI. Apart from this some updates/fixes have been made in NSMF, RAN/Core/TN NSSMF functionality in SO, for + example: + + (a) *NSMF*: Update NSI selection process support shared NSI and add sst parameter + (b) *AN NSSMF*: Activation flow for SDN-R interactions, allocate flow & added timeDelay in QueryJobStatus, + support of Option 1 for topmost RAN NSSI + (c) *CN NSSMF*: Non-shared allocate flow + (d) *TN NSSMF*: Modify TN NSSI operation + +- **CPS**: 2 APIs required for the use case are supported. The remaining yang models are also onboarded, + however, the API work as well as further enhancements to CPS Core, NF Proxy and Template-Based Data + Model Transformer Service shall continue beyond Honolulu. + +- **SDN-R**: RRMP Policy updates, enhancements for updating the RAN configuration during slice reuse, + closed loop and intelligent slicing. + +- **DCAE**: + + (a) *KPI Computation MS*: This MS was introduced newly for computation of slice related KPIs. In this release, + it supports basic KPI computation based on formula specified via Policy. Further details about this MS is + available at `KPI Computation MS <https://wiki.onap.org/display/DW/DCAE+R8+KPI-Computation+ms>`_ + (b) *Slice Analysis MS*: Minor updates were done. + +Apart from the above, Policy and SDC had test-only impact for this use case. + +In addition: + +- **Config DB** was updated to handle bugs and gaps found during testing. This is not an official ONAP component, and + its functionality is expected to be performed fully by the Configuration Persistence Service (CPS) in future ONAP + release (beyond Honolulu). + +- **Core NF simulator** and *ACTN simulator* were also updated and checked into ONAP simulator repo. + +- **RAN-Sim** has been updated to fix bugs found during testing, and also checked into ONAP simulator repo. + + +Functional Test Cases +--------------------- +The functional testing of this use case shall cover CSMF/NSMF, the 3 NSSMFs and Closed Loop functionality. We classify the +test cases into 5 tracks: CSMF/NSMF, RAN NSSMF, Core NSSMF, TN NSSMF and Closed Loop. +Details of the test cases can be found at: +`Integration Test details for Honolulu <https://wiki.onap.org/display/DW/Integration+Test+details+for+Honolulu>`_ and its child wiki pages. Operation Guidance ------------------ +The Honolulu release setup details for the E2E Network Slicing use case will be available at the following page and its +sub-pages: +`User Operation Guide for Honolulu release <https://wiki.onap.org/display/DW/User+Operation+Guide+for+Honolulu+release>`_ + + +Known Issues and Resolutions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Details of manual configurations, work-arounds and known issues will be documented in the child wiki pages of: +`User Operation Guide for Honolulu release <https://wiki.onap.org/display/DW/User+Operation+Guide+for+Honolulu+release>`_ + +The foll. integration tests are carried over to Istanbul release: see `REQ-721 <https://jira.onap.org/browse/REQ-721>`_ +- NSMF: Option 2 testing, remaining regression testing and service termination testing for NSMF +- RAN NSSMF: RAN NSSI termination, interactions with TN NSSMF for FH/BH NSSI reuse and some minor aspects related to SDN-R <-> RAN interaction +- TN NSSMF: Checking some minor aspects in SO for modifying TN NSSI. +- Core NSSMF: Modifying and deallocating a Core NSSI, reusing an existing Core NSSI +- KPI Computation, Closed Loop & Intelligent Slicing: Some minor aspects on SDN-R <-> RAN-Sim interface needs to be addressed. + +Further details of these test cases can be found in REQ jiras for integration testing for Honolulu, and in the +use case wiki. This means that the functionality associated with these test cases may require updated versions +of the relevant components - the User Operation Guide will also be updated with details of any bug fixes +beyond Honolulu as the testing is anyhow continuing as part of Istanbul release. + +Istanbul release updates +------------------------ +Below aspects are covered in Istanbul release: + +1. **CPS-TBDMT Enhancements** - This service shall be used to map the erstwhile Config-DB-like REST APIs to appropriate CPS API calls. The purpose of this service is to abstract the details of (possibly multiple, and complex) XPath queries from the users of CPS. It enables CPS-users to continue using simple REST API calls that are intuitive and easy-to-understand and implement. The mapping to appropriate queries to CPS (including mapping of one API call to many Xpath queries) shall be done in a generic way by the CPS-TBDMT service. In Istanbul release, following are the main enhancements done: + + - Support edit query ie. post, put and patch requests to CPS + + - Support Output Transformation + + (a) Extract desired output from the data returned from CPS. + (b) If 'transformParam' is not defined in the template no transformation takes place. + - Support Multiple query + + (a) Make multiple queries to CPS in single request. + (b) If 'multipleQueryTemplateId' is mentioned in the template, it will execute this template first and insert the result to the current template to make multiple queries to CPS. + - Support Delete data requests to CPS + + (a) Process delete request type. + - Support for dynamic anchor - Accept anchors at run time and execute query + +2. **CPS Integration** + + - Config DB is replaced with the CPS component to read, write, update and delete the RAN Slice details. CPS APIs are accessed via CPS-TBDMT component. CPS integration with DCAE - Slice Analysis MS and OOF are completed. SDN-R integration with CPS is completed for the shared RAN Slice flow, activateRANslice and terminateRANSlice implementations are in progress. + - A new SDN-C karaf feature is introduced to register the cm-handle (anchor) with CPS. The integration with CPS-DMI plugin will be done in Jakarta release. + +3. **NSMF based TN Slices** - Support for interacting with TN NSSMF directly from NSMF for front haul and mid haul slice subnets. There will be separate SDC template for this scenario. NST will have 5 NSSTs - CN NSST, AN NSST, TN FH NSST, TN MH NSST, TN BH NSST. + +4. **KPI Monitoring** - Implementation is done in KPI Computation MS to configure the required KPIs and the KPI computation formula based on policies. + +5. **Closed Loop** - Closed Loop updates are sent over A1 interface to Near-RT RIC. This is done at the POC level. This will be further enhanced in Jakarta release to make use of the A1-Policy Management Service in CCSDK. + +6. **Intelligent Slicing** - End to end intelligent slicing - closed loop flow is tested with the initial version of Machine Learning MS. + +7. **Carry-over Testing from Honolulu Release** + + - RAN NSSMF Testing + + (a) Testing completed for the allocation, modification, activation and deactivation of the RAN slice to support option1 + (b) Integration Testing of AN NSSMF with SDNR interactions for allocate and modify flow is completed + - E2E Testing + + (a) Service instantiation for non-shared and shared scenario and fixes to support option 1 are done + (b) NSI selection process support for shared NSI is tested + +Impacted Modules for Istanbul Release +------------------------------------- +- **SO** + (a) Support of NSI termination by enhancing the interaction with OOF, AAI and UUI + (b) RAN NSSI Termination support with OOF & SDN-R interactions + (c) Bug fixes in Option 1 (CSMF, NSMF and NSSMFs are within ONAP & TN-FH, TN-MH are created by RAN NSSMF) + - **CSMF**: Fixed sNSSAI format and updated authentication for NSMF invocation + - **NSMF**: Fixes in NSI termination issues to support OOF interaction for NSI termination query and added subnet Type support for respective TN Domain + - **AN NSSMF**: Fixes for different termination scenarios in Option 1 + - **CN NSSMF**: Bug fixes in shared allocate flow, modify flow and terminate flow + - Slice Profile alignment with NSSMF + (d) NSMF based TN Slices (TN-FH, TN-MH are created by NSMF) - Work flow changes to support this approach + +- **OOF** + (a) Integration with CPS for coverage area to coverage area TA list + (b) Bug fixes in NxI termination + +- **DCAE** + (a) Minor changes in Slice Analysis MS to support CPS integration + (b) KPI Computation MS in enhanced to support policy based KPIs and formula + +- **SDN-R** + (a) Bug fixes in instantiateRANSliceAllocate, instantiateRANSliceAllocateModify, activateRANSlice, terminateRANSlice Directed Graphs + (b) CPS integration for the instantiateRANSliceAllocateModify, activateRANSlice, terminateRANSlice Directed Graphs + (c) A new karaf feature is introduced to register the cm-handle with CPS + +- **CPS-TBDMT** + (a) This component is enhanced to support different type of queries based on templates + +- **CPS** + (a) Bug fixes and support for GET, POST, PATCH and DELETE type of queries. + +Istanbul Release - Functional Test cases +---------------------------------------- +**Honolulu release carry-over test cases** + (a) Different possible scenarios of E2E Slice (eMBB) creation are tested in I-release + (b) RAN slice Termination testing completed + (c) Test cases to validate slice reuse and terminate using Option 2 (Core NSSMF and RAN NSSMF external) are completed + +**R9 Integration Testing** + (a) RAN NSSMF integration with CPS is covered for RANSlice modification, activation, deactivation and termination + (b) NSMF driven TN-FH and TN-MH slices creation is tested + (c) CPS impacts in closed loop scenario is validated and few test cases are deferred to Jakarta release + + Integration test plan is available at `Integration Testing in Istanbul Release <https://wiki.onap.org/display/DW/R9+Integration+Test+for+E2E+Network+Slicing>`_ + +Istanbul Release - Operation Guidance +------------------------------------- +The steps for E2E network slicing use case will be available at `User Operation Guidance - Istanbul Release <https://wiki.onap.org/pages/viewpage.action?pageId=111118867>`_. It is an update to the user manual created in Honolulu release. + +Istanbul Release - Known issues and Solutions +--------------------------------------------- + +**REGISTER 3RD PARTY CONTROLLERS** + +The ONAP TSC approved on July 9th, 2020 to change the status of ESR GUI Module +to an 'unmaintained' project. Further information about 'Unmaintained Projects' +can be found in the `ONAP Developer Wiki. <https://wiki.onap.org/x/Pw_LBQ>`__ + +But excluding the ESR GUI module from ONAP does not mean that the "external +system registration" mechanism is excluded; i.e. only the GUI is not available +anymore. + +Nevertheless, in order to register the 3rd party controllers (like it is done +in E2E network slicing use case and recently in Cloud Leased Line "CLL" use +case as part of Intent-Based Networking), AAI's API are invoked manually. + +To do so, please send the following CURL command (PUT) to your AAI, with the +attached xml payload. In the payload, please adjust the controller name (in +this case sdnc1) and the controller ip address accordingly based on your +environment: + +CURL COMMAND: + +.. code-block:: bash + + curl -k -X PUT https://{{your-onap-ip-address}}:30233/aai/v16/external-system/esr-thirdparty-sdnc-list/esr-thirdparty-sdnc/sdnc1 -u "AAI:AAI" -H "X-FromAppId:postman" -H "Content-Type:application/xml" -H "Accept: application/xml" -H "X-TransactionId:9999" -d @/home/onap/esr-registration-controller-1.xml + + +PAYLOAD (esr-registration-controller-1.xml): + +.. code-block:: xml + + <?xml version="1.0" encoding="UTF-8"?> + <esr-thirdparty-sdnc xmlns="http://org.onap.aai.inventory/v16"> + <thirdparty-sdnc-id>sdnc1</thirdparty-sdnc-id> + <location>Core</location> + <product-name>TSDN</product-name> + <esr-system-info-list> + <esr-system-info> + <esr-system-info-id>sdnc1</esr-system-info-id> + <system-name>sdnc1</system-name> + <type>WAN</type> + <vendor>Huawei</vendor> + <version>V3R1</version> + <service-url>http://192.168.198.10:18181</service-url> + <user-name>onos</user-name> + <password>rocks</password> + <system-type>nce-t-controller</system-type> + <protocol>RESTCONF</protocol> + <ssl-cacert>example-ssl-cacert-val-20589</ssl-cacert> + <ssl-insecure>true</ssl-insecure> + <ip-address>192.168.198.10</ip-address> + <port>26335</port> + <cloud-domain>example-cloud-domain-val-76077</cloud-domain> + <default-tenant>example-default-tenant-val-71148</default-tenant> + <passive>true</passive> + <remote-path>example-remotepath-val-5833</remote-path> + <system-status>example-system-status-val-23435</system-status> + </esr-system-info> + </esr-system-info-list> + </esr-thirdparty-sdnc> + + +Additional issues occurred during the deployment and integration testing will be +listed in the ONAP Developer Wiki at `Network Slicing - Issues and Solutions <https://wiki.onap.org/display/DW/Network+Slicing+-+Issues+and+Solutions>`_ + +Jakarta Release Updates +----------------------- +In Jakarta release, the following aspects are covered: + +1. **E2E Network Slicing Solution** + - Slice selection based on resource occupancy level. With this enhancement, NSMF/NSSMF is able to monitor and update resource levels at NSI/NSSI level. OOF returns the solution for NSI/NSSI selection based on the criteria. In case of shared scenario, NSI/NSSI can be shareable only if sufficient resources are available in the network. RAN NSSMF’s resource occupancy is considered for this release. Resource occupancy of Core and TN NSSMFs will be considered in future releases. +2. **RAN Slicing** + - Optimization of cm-handle registration with CPS-DMI Plugin for RAN NF instances to upload yang model. + - CPS integration with SDN-R for RAN slice allocation and reconfiguration scenarios + - CPS integration stabilization for RAN slice activate/deactivate and terminate scenarios. Validation and bug fix for CPS integration of RAN slice lifecycle. +3. **Transport Slicing** + - OOF involvement in TN slice reuse and terminate scenarios + - Implementation of the call to OOF for allocateNSSI to enable TN NSSI reuse in TN NSSMF + - Implementation of the call to OOF for terminateNxi API to deallocate TN NSSI (which may not be terminated even when NSI is terminated) in TN NSSMF + - Closed-loop enhancement in CCVPN to support Transport Slicing’s closed-loop (Covered in CCVPN use case). +4. **Closed Loop** + - IBN based Closed loop for Network Slicing. This enhancement makes use of intents and Machine Learning models for closed loop. ML prediction microservice enhancement is done as a POC work in Jakarta release. + - CPS integration stabilization, which validates and enhances CPS integration for closed loop. +5. **Carryover tests from Istanbul release** + - Option-1 (internal NSMF, NSMF and NSSMF) + - Pending test cases for E2E Slice termination + - Bug fixes and testing for Core slicing + - NF instantiation issue with same NSST + - Multiple non-share Core slice creation issue + +Impacted Modules for Jakarta Release +------------------------------------ +- **SO**: Requirements below are identified for Jakarta release and have impacts in SO component: + (1) Use of Optimization solution (OOF) in allocateNSSI, deallocateNSSI in TN NSSMF + (2) Bug fixes/enhancements of carryover test cases from Istanbul release + +- **OOF**: OOF component has an impact for the requirement below: + (1) NSI/NSSI Selection enhancements based on resource occupancy levels + +- **DCAE**: The requirements below are identified for Jakarta release and have impacts in DCAE component: + (1) Slice selection taking into consideration of resource occupancy levels + (2) CPS integration in closed loop – This was done in I-release. Expecting minor enhancements in Slice Analysis MS once after the other components impacts w.r.t CPS integration and E2E testing are completed. + (3) IBN based Closed loop for Network Slicing - This will have impact in E2E Slicing closed loop and TN Slicing closed loop. + +- **CCSDK**: The requirements below are identified for network slicing use case in Jakarta release and have impacts in CCSDK component. Most of these requirements fall under the category of CPS integration. + (1) Optimizing cm-handle registration with CPS-DMI Plugin to upload yang model + (2) CPS Integration with SDN-R for RAN Slice allocate and reconfigure scenarios + (3) CPS Integration Stabilization - RAN Slice activate/deactivate and terminate scenarios + +Jakarta Release - Functional Test cases +--------------------------------------- +The functional testing of this use case covers CSMF/NSMF, RAN/CN/TN NSSMFs and Closed Loop functionality. Test cases are classified into 5 tracks: E2E network slicing, RAN NSSMF, TN NSSMF, Closed Loop and carryover testing. Details of the test cases can be found at: `E2E Network Slicing Tests for Jakarta Release <https://wiki.onap.org/display/DW/E2E+Network+Slicing+Integration+Tests+for+Jakarta+Release>`_ and its child wiki pages. + +Jakarta Release - Operation Guidance +------------------------------------ +The setup and operation details for E2E network slicing use case are available at `User Operation Guidance - Jakarta Release <https://wiki.onap.org/display/DW/User+Operation+Guidance+-+Jakarta+Release>`_. + +Jakarta Release - Automate Network Slicing Option2 preparation step +------------------------------------------------------------------- + +Automation of the Network Slicing Option2 use case is under development. At this moment automation of the preparation step is completed, with the source code under `SMO package repo <https://github.com/sebdet/oran-deployment>`_. The detailed introduction of the framework can be found at `SMO package introduction <https://wiki.o-ran-sc.org/display/IAT/Automated+deployment+and+testing+-+using+SMO+package+and+ONAP+Python+SDK>`_. + +The preparation scripts are python scripts, based on the ONAP pythonsdk framework. More libraries are added under SMO package in order to run the preparation scripts. + +The preparation scripts locate in folder **test/pythonsdk/src/orantests/network_slicing**. Before running the script, please open **settings.py** under folder **test/pythonsdk/src/orantests/configuration**. Make sure the URL settings for all the components are the good values. + +If the settings are good, go to folder **test/pythonsdk/src/orantests/network-slicing** and run the following command to trigger the preparation script: + + +.. code-block:: bash + + cd ./test/pythonsdk/src/orantests/network-slicing + tox -e ns-tests + +The command will trigger the main script **test_network_slicing.py**, which in turn triggers the preparation script of each component. + +The whole preparation process will configure the components and also verifies a bit whether the configuration was done successfully at the end of each step. + +The whole process may take about 1 hour to complete. You can monitor the progress using the log file **pythonsdk.debug.log** located in the folder **network_slicing/preparation**. + +If everything goes fine, you will see similar logs as shown below in the end. + +.. image:: files/ns_automation/ns_automation_suc.png + +If things goes wrong, please read the logs to identify which part has go wrong and try to fix that step manually. + +Then you can update the **test_network_slicing.py**, disable steps that are already complete, and replay the tox command to complete the rest of the configuration. + + +Please note, when checking **test_network_slicing.py** in details, you will find some of the preparation steps might require extra input parameters, such as **cst_id**, **cst_invariant_id** and **sp_id**. These values could be found in both logs and SDC UI. + +.. image:: files/ns_automation/ns_automation_test_class.png + +In case it failed in the middle of the SDC template creation, please update the **sdc_template_suffix** variable inside the **test_network_slicing.py** and then rerun the script with tox command. + +Since SDC doesn't support creating template with the same name, neither deleting of any templates, you have to add a suffix to the original name to create template with a new name. + +.. image:: files/ns_automation/ns_automation_sdc_suffix.png + + +Jakarta Release - Known issues and Solutions +-------------------------------------------- +Details of up to date manual configurations, known issues, solutions and work-arounds can be found in the following wiki page: `Jakarta Release - Issues and Solutions <https://wiki.onap.org/display/DW/Jakarta+Release+-+Issues+and+Solutions>`_. + +Kohn Release Updates +----------------------- +In Kohn release, the following enhancements are implemented: + +- IBN driven E2E Network Slicing support including enhancement to Slice Analysis MS to listen to real-time user intents posted by AAI using DCAE SDK dmaap-client lib and and report slice KPI to UUI. +- KPI computation enhancements including new KPI added and new UUI display design, KPI spanning multiple resources, error handling for missing counters. +- DCAE R11 global requirements contribution `(See the wikipage here) <https://wiki.onap.org/display/DW/R11+Global+requirements+Contribution>`_. + +Kohn release also fixed a few critical bugs in Jakarta release. + +Impacted Modules for Kohn Release +------------------------------------ +- **DCAE**: Requirements below for Kohn release have impacts on DCAE component: + (1) Enhancement to Slice Analysis MS + (2) KPI computation enhancements + (3) DCAE R11 global requirements and bug fixes + +- **UUI**: Requirements below for Kohn release have impacts on UUI component + (1) Slicing KPI monitoring and display for IBN driven network slicing + +Kohn Release Functional Test Cases +--------------------------------------- +Details of the test cases can be found at: `E2E Network Slicing Tests for Kohn Release <https://wiki.onap.org/display/DW/E2E+Network+Slicing+Integration+Tests+for+Kohn+Release>`_ and its child wiki pages. + +London Release Updates +----------------------- +The following enhancements are added to the London release: + +- Support of 3GPP 28.532 based APIs for network slicing + +Impacted Modules for London Release +------------------------------------ +- **SO**: Requirements below for London release have impacts on SO component: + (1) Enhancement to SO macro flow to support 3GPP 28.532 based APIs for network slicing + (2) NSST selection APIs for integration with OOF + +- **OOF**: Requirements below for Londond release have impacts on OOF component: + (1) NSST selection APIs for integration with SO -How to install 5G E2E Slicing Minimum Scope -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For 5G E2E Slicing use case, we support the minimum-scope installation -of ONAP to reduce the resource requirements. From the module -perspective, 5G E2E Slicing use case involves SDC, SO, A&AI, UUI, -EXT-API, OOF and Policy modules of ONAP. So we will configure these -required modules along with the mandatory common modules such as DMaaP. -Further, for each module, the use case also does not use all of the -charts，so we removed the not needed Charts under those modules to -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 - - -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 +London Release Test Cases +-------------------------- +Details of the test cases can be found at: `E2E Network Slicing Tests for London Release <https://wiki.onap.org/display/DW/E2E+Network+Slicing+Integration+Testing+for+London+Release>`_. diff --git a/docs/docs_NFV_Testing_Automatic_Platform_Requirements_User_Guide.rst b/docs/docs_NFV_Testing_Automatic_Platform_Requirements_User_Guide.rst new file mode 100644 index 000000000..65d0e41a3 --- /dev/null +++ b/docs/docs_NFV_Testing_Automatic_Platform_Requirements_User_Guide.rst @@ -0,0 +1,130 @@ +.. nfv_testing_automation_platform_requirements: + +:orphan: + +======================================================= +NFV Testing Automatic Platform Requirements- User Guide +======================================================= + +.. Overview: this page used to explain how to use NFV testing automatic platform, + the relevant requirements include REQ-335(Support for Test Topology + Auto Design), REQ-336(Support for Test Environment Auto Deploy), + REQ_337(Support for Test Task Auto Execution),REQ-338(Support for + Test Result Auto Analysis & Certification). + +Description +=========== + +There are a large number of cross-department and cross-organization communications +during the traditional network element, system or equipment network access test. +And the manual errors are inevitable, the knowledge in test field cannot be +solidified. The cost of each test is high and the test cycle is always long. +After introducing NFV, because network element software and hardware equipment are +layered decoupled, the introduction of a large number of open source components as +well as the frequent upgrade of the software itself, make network access test +become more complicated and frequent. + +Testing has become a bottleneck during the introduction and iteration of new +technologies. Therefore, it is urgent to introduce automated test tools. +By introducing testing automatic capabilities including topology auto design, +test environment auto deploy, test task auto execution and test result auto +analysis & certification, it can solidify domain knowledge, and help reduce labor +costs, shorten test cycle, improve test efficiency , optimize test accuracy. + +Requirement Details +=================== + +Test Topology Auto Design( enhancement in SDC) +---------------------------------------------- + +1.Quickly design a test service (topology) composed with tested VNF and test + environment (One way is to define abstract testing service (topology) template + for each type of VNF); + +2.For the service designed, can be imported into SDC for modification or enhancement, + or the test template can be reused for different test environments (the SDC needs + to support service import). + +Test Environment Auto Deploy (enhancement in VF-C) +-------------------------------------------------- + +By getting VM/VL/Port/VNF/NS instance information from Openstack via Multi-cloud +to VF-C for instance information storage, enable VTP obtaining all the real-time +instance information. + +Test Task Auto Execution(enhancement in VNFSDK, CLI) +---------------------------------------------------- +1. Test instruments integration： + +* Test Case execution; +* Test Case discovering and auto registration; +* Robot profile integration + +2. VTP capability expansion: + +* Loading different test scripts and cases- Scenario Active Management ; +* Flexible test process definition(Middle); +* Test report customization +* Profile HTTP API support + +3. Execution-Standard / Open source test case support + +* Enable ETSI NFV APIs conformance test cases in VTP; +* Enable CNCF CNF conformance test case in VTP. + +4. Test Result Auto Analysis & Certification + +* The test objects that passed test certification are put into marketplace +* OVP integrates with VTP to automatically receive VTP test results: + + * Enable OVP with HTTP API for submit the result + * Enable VTP for result submission into OVP. + +New Features and Guide (Guilin Release) +======================================= + +SDC New features +---------------- + +Service import +>>>>>>>>>>>>>> + +1. Add a button “IMPORT SERVICE CSAR" to perform service CSAR import. +2. When clicking the “IMPORT SERVICE CSAR” button on the portal, a window will + pop up to select the service CSAR file to be imported. +3. After selecting the service CSAR file to be imported, it will switch to the + general information input page for creating the service. +4. After filling in all the required fields, you can click the "create" button + to create a new service. +5. Add a new API for the request of importing service CSAR. + +Abstract service template +>>>>>>>>>>>>>>>>>>>>>>>>> + +1. On the general page of VF, add a IS_ABSTRACT_RESOURCE selection box, which is + false by default. If it is an abstract VNF, select true manually. +2. Add three APIs to handle the corresponding requests of abstract service template: + 2.1 Return whether the service is a abstract service: GET /v1/catalog/abstract/service/serviceUUID/{uuid}/status + 2.2 Copy a new service based on the existing service: POST /v1/catalog/abstract/service/copy + 2.3 Replace the abstract VNF in the abstract service template with the actual VNF: PUT /v1/catalog/abstract/service/replaceVNF + +VTP New features +---------------- +1. Added active scenario and profile management support +2. Added integration with Robot CSIT tests +3. Enabled auto discovery of test cases from 3rd party tool integration +4. Added support for cnf-conformance test support( In order to enable CNF + conformance tool in VTP, please refer `the guide <https://gerrit.onap.org/r/gitweb?p=vnfsdk/validation.git;a=blob;f=cnf-conformance/README.md;h=cda3dee762f4dd2873613341f60f6662880f006a;hb=refs/heads/master>`_ +5. New VTP API has been updated: see the `VTP API wiki page <https://wiki.onap.org/display/DW/VTP+REST+API+v1>`_ + +CLI New features +---------------- + +1. Enabled auto discover and registration of products functionalities as commands +2. Profile management commands are added +3. For the VTP Command line usage, please refer :ref:`CLI User Guide <onap-cli:cli_user_guide>` + +Test Status and Plans +===================== + +See `the status of the test wiki page <https://wiki.onap.org/display/DW/Automatic+Testing+Requirements>`_ diff --git a/docs/docs_StndDefined_Events_Collection_Mechanism.rst b/docs/docs_StndDefined_Events_Collection_Mechanism.rst new file mode 100644 index 000000000..89c6481c4 --- /dev/null +++ b/docs/docs_StndDefined_Events_Collection_Mechanism.rst @@ -0,0 +1,97 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 + International License. http://creativecommons.org/licenses/by/4.0 + +:orphan: + +.. _docs_StndDefined_Events_Collection_Mechanism: + +VES Collector - Standard Defined Events Collection Mechanism +------------------------------------------------------------ + +Description +~~~~~~~~~~~ + +The target of standard defined events collection mechanism development was to allow collection of events defined by standards organizations using VES Collector, +and providing them for consumption by analytics applications running on top of DCAE platform. The following features have been implemented: + +1. Event routing, based on a new CommonHeader field “stndDefinedNamespace” +2. Standards-organization defined events can be included using a dedicated stndDefinedFields.data property +3. Standards-defined events can be validated using openAPI descriptions provided by standards organizations, and indicated in stndDefinedFields.schemaReference + +`Standard Defined Events Collection Mechanism description <https://docs.onap.org/projects/onap-dcaegen2/en/jakarta/sections/services/ves-http/stnd-defined-validation.html>`_ + +.. note:: + + VES Collector orchestrated using Helm or Cloudify uses standard defined domain schema files bundled within VES collector image during image build. + Also new Helm based installation mechanism for collectors doesn't support yet certain features available with the traditional Cloudify orchestration based mechanisms: + - Obtaining X.509 certificates from external CMP v2 server for secure xNF connections + - Exposing the Collector port in Dual Stack IPv4/IPv6 networks. + + +How to Configure VES Collector +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +By default config maps containing schema files are defined in the `OOM <https://github.com/onap/oom/tree/jakarta/kubernetes/dcaegen2-services/resources/external>`_ repository and installed with dcaegen2 module. +In Istanbul release in OOM are used schema files from https://forge.3gpp.org/rep/sa5/MnS/blob/SA88-Rel16/OpenAPI/. +The newest schema files can be found in https://forge.3gpp.org/rep/sa5/MnS/tree/Rel-16-SA-91/OpenAPI +If for production/test purpose are required different or newest schema files please follow procedure for `config map update <https://docs.onap.org/projects/onap-dcaegen2/en/latest/sections/configuration.html#config-maps>`_. + +In order to prepare second instance of VES Collector please follow below procedure: + +1. (Optional step) If VES Collector should obtaining X.509 certificates from CMPv2 server for secure xNF connections please follow below steps: + + - Install `Cert Manager <https://docs.onap.org/projects/onap-oom/en/latest/sections/guides/infra_guides/oom_infra_base_config_setup.html#install-cert-manager>`_ + - Configure `Cert Service <https://docs.onap.org/projects/onap-oom-platform-cert-service/en/jakarta/sections/configuration.html>`_ if external CMP v2 server is in use. + +2. If usage of config maps from OOM containing schema files is required please follow procedure for + `external repo schema files from OOM connection to VES collector <https://docs.onap.org/projects/onap-dcaegen2/en/jakarta/sections/services/ves-http/installation.html#external-repo-schema-files-from-oom-connection-to-ves-collector>`_ + with changes described below. + + As new instance of VES Collector will be introduced to ONAP namespace there is need to modify parameters from ``/inputs/k8s-ves-inputs-tls.yaml`` in Bootstrap POD + + - external_port - set here ``node port`` from range ``30000-32767`` not used in ONAP instance for example ``30519`` + - ``service_component_type``, ``service_id``, ``service_component_name_override`` - set here custom service name e.g. ``dcae-ves-collector-std-def-evnents`` + + (Optional step) If VES Collector should also obtaining X.509 certificates from CMP v2 and its clients should successfully validate its hostname then following parameters need to modified in ``/inputs/k8s-ves-inputs-tls.yaml`` file. + + - ``external_cert_use_external_tls`` - change from ``false`` to ``true`` + - ``external_cert_common_name`` - set same value as used in ``service_component_name_override parameter`` + - ``service_component_name_override`` - add following values: + - all IPv4 addresses of ONAP worker hosts + - all IPv6 addresses of ONAP worker hosts + - all FQDN names of ONAP worker hosts + - ``service_component_name_override`` parameter value. + + Deploy new instance of VES collector using ``/inputs/k8s-ves-inputs-tls.yaml`` + +3. (Optional step) If ONAP is installed in Dual Stack and VES Collector should listen in IPv6 network + + - on RKE node prepare file ``ves-ipv6.yaml`` with following content (below is an example of file for ``dcae-ves-collector-std-def-evnents`` service name created in section 2, in ``node port`` set once again value from range ``30000-32767`` not used in ONAP instance for example ``30619`` ) + .. code-block:: bash + + apiVersion: v1 + kind: Service + metadata: + name: xdcae-ves-collector-std-def-evnents + namespace: onap + spec: + externalTrafficPolicy: Cluster + ipFamily: IPv6 + ports: + - name: xdcae-ves-collector-std-def-evnents + nodePort: 30619 + port: 8443 + protocol: TCP + targetPort: 8443 + selector: + app: dcae-ves-collector-std-def-evnents + sessionAffinity: None + type: NodePort + + - apply prepared service and check if it working + .. code-block:: bash + + kubectl -n onap apply -f ves-ipv6.yaml + + kubectl -n onap get svc | grep collector-std-def-evnents + xdcae-ves-collector-std-def-evnents NodePort fd00:101::6ad <none> 8443:30619/TCP diff --git a/docs/docs_Testing_5G_PNF_Software_Upgrade_With_Schema_Update.rst b/docs/docs_Testing_5G_PNF_Software_Upgrade_With_Schema_Update.rst new file mode 100644 index 000000000..eb549bb99 --- /dev/null +++ b/docs/docs_Testing_5G_PNF_Software_Upgrade_With_Schema_Update.rst @@ -0,0 +1,189 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +.. _docs_testing_5g_pnf_software_upgrade_with_schema_update: + + +:orphan: + +Testing xNF Software Upgrade in association to schema updates +------------------------------------------------------------- + +Description +~~~~~~~~~~~ +This procedure only describes the test instruction to upgrade schema of a service instance with at least one PNF resource based on a new onboarding package. + +This procedure can be used to upgrade a service instance with more than one PNF resource. + +A. Pre-conditions +~~~~~~~~~~~~~~~~~ +* A service template with at least one PNF resource has been created in SDC and distributed to run time + +* At least one service instance has been instantiated, including PNF registration and configuration, in run time + +* This service instance is in health condition + +* A new PNF onboarding package, which contains a new software version and new artifacts, is ready for onboarding + +* This procedure does not support addition of new PNF resource or deletion of existing PNF resource in the service template. + + +B. Update and re-distribute the service template: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + The service template must be updated with updated schema information for the PNF resources, and then redistributed to run time. + + 1. Update an existing PNF resource artifact and attach the same to an existing service template. + + - url to portal: https://portal.api.simpledemo.onap.org:30225/ONAPPORTAL/login.htm + + - password for users: demo123456! + + - Login as cs0008, go to "ONBOARD", where all the available VSPs and Services are listed. + + + 2. Follow below mentioned procedure to update VSP and Service. + + - `Update VF/PNF <https://docs.onap.org/en/kohn/guides/onap-user/design/resource-onboarding/index.html#update-vfcs-in-a-vsp-optional>`_ + + - `Update Service <https://docs.onap.org/en/kohn/guides/onap-user/design/service-design/index.html#update-service-optional>`_ + + +C. Trigger PNF service level software upgrade with schema update: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + Schema update procedure can be triggered manually by invoking appropriate rest end points through the postman client. + + 3. Get the service level workflow uuid by fetching all the available workflows from SO: + + - GET http://REPO_IP:SO_PORT/onap/so/infra/workflowSpecifications/v1/workflows + + - From the response, fetch the workflow uuid against the workflow name “ServiceLevelUpgrade”. + + .. image:: files/softwareUpgrade/workflowList.png + + + 4. Select one service instance which need to be upgraded + + - Retrieve all services instance from AAI using: + + - GET https://REPO_IP:AAI_PORT/business/customers/customer/{global-customer-id}/service-subscriptions/service-subscription/{service-type}/service-instances + + - Select one service instance from the service instance list received from above query. + + + 5. Get all Service-Model-Version from AAI Using Service-Model-InVariant-UUId: + + - Use the Service-Model-InVariant-UUId from the selected service instance (previous step) as model-invariant-id in this query. + + - GET https://REPO_IP:AAI_PORT/aai/v21/service-design-and-creation/models/model/${model-invariant-id}/model-vers + + - Select one model version Id from the model version list received from above querying. The selected model version Id will be used as the target service model version at upgrade procedure. + + .. image:: files/softwareUpgrade/serviceModelVersions.png + + + 6. Invoke the service level upgrade workflow to update the schema of xNF resources. + + - Invoke the service level workflow by passing the older version service model id and the service level workflow uuid for “Service Level workflow” fetched in the previous steps. + + - In the body of the POST request, json input needs to be supplied that contains info on the model version to which we are going to trigger the update. (2.0) + + - POST http://REPO_IP:SO_PORT/onap/so/infra/instanceManagement/v1/serviceInstances/${serviceInstanceId}/workflows/${serviceLevel_workflow_uuid} + + - Attaching below a sample request json : + +{ + + "requestDetails": { + + "subscriberInfo": { + + "globalSubscriberId": "807c7a02-249c-4db8-9fa9-bee973fe08ce" + + }, + + "modelInfo": { + + "modelVersion": "2.0", + + "modelVersionId": "8351245d-50da-4695-8756-3a22618377f7", + + "modelInvariantId": "fe41489e-1563-46a3-b90a-1db629e4375b", + + "modelName": "Service_with_pnfs", + + "modelType": "service" + + }, + + "requestInfo": { + + "suppressRollback": false, + + "requestorId": "demo", + + "instanceName": "PNF 2", + + "source": "VID" + + }, + + "requestParameters": { + + "subscriptionServiceType": "pNF", + + "userParams": [ + + { + + "name": "targetSoftwareVersion", + + "value": "pnf_sw_version-4.0.0" + + } + + ], + + "aLaCarte": false, + + "payload": "{\"k1\": \"v1\"}" + + }, + + "project": { + + "projectName": "ServiceLevelUpgrade" + + }, + + "owningEntity": { + + "owningEntityId": "67f2e84c-734d-4e90-a1e4-d2ffa2e75849", + + "owningEntityName": "OE-Test" + + } + + } + +} + +Note down the request id for the schema update request that can be used in the subsequent steps to track the progress. + + + 7. Verify the service level upgrade workflow status + + - GET http://REPO_IP:SO_PORT/onap/so/infra/orchestrationRequests/v7/${requestID} + + - Verify the response status code and message for the request id fetched in the previous step. + + - For successful upgrade completion, the response code must be “200” with appropriate success message. + + + 8. Verify PNF Configuration for Service Level Upgrade from AAI + + - GET https://REPO_IP:AAI_PORT/aai/v16/network/pnfs/pnf/{PNF_NAME} + + - Verify the software version of the pnf resource updated in AAI. + + .. image:: files/softwareUpgrade/verifyPNF.png diff --git a/docs/docs_pnf_onboarding_preonboarding.rst b/docs/docs_pnf_onboarding_preonboarding.rst index bf38ca569..fb33ec370 100644 --- a/docs/docs_pnf_onboarding_preonboarding.rst +++ b/docs/docs_pnf_onboarding_preonboarding.rst @@ -3,6 +3,8 @@ .. _docs_pnf_onboarding_preonboarding: +:orphan: + 5G - PNF Pre-Onboarding & Onboarding ------------------------------------ diff --git a/docs/docs_robot.rst b/docs/docs_robot.rst index 96b4b7c65..f572f2799 100644 --- a/docs/docs_robot.rst +++ b/docs/docs_robot.rst @@ -3,6 +3,8 @@ .. _docs_robot: +:orphan: + Robot ----- diff --git a/docs/docs_scaleout.rst b/docs/docs_scaleout.rst index 6b88168da..80ee6bf95 100644 --- a/docs/docs_scaleout.rst +++ b/docs/docs_scaleout.rst @@ -1,27 +1,191 @@ .. _docs_scaleout: +:orphan: + VF Module Scale Out Use Case ---------------------------- Source files ~~~~~~~~~~~~ -- Heat templates directory: https://git.onap.org/demo/tree/heat/vLB_CDS?h=elalto +- Heat templates directory: https://git.onap.org/demo/tree/heat?h=guilin +- Heat templates directory (vLB_CDS use case): https://git.onap.org/demo/tree/heat/vLB_CDS?h=guilin Additional files ~~~~~~~~~~~~~~~~ - TOSCA model template: https://git.onap.org/integration/tree/docs/files/scaleout/service-Vloadbalancercds-template.yml -- Naming policy script: https://git.onap.org/integration/tree/docs/files/scaleout/push_naming_policy.sh +- Naming policy script: :download:`push_naming_poliy.sh <files/scaleout/push_naming_policy.sh>` +- Controller Blueprint Archive (to use with CDS) : https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/service-blueprint/vLB_CDS_Kotlin?h=guilin +- TCA blueprint: :download:`guilin-tca.yaml <files/scaleout/latest-tca-guilin.yaml>` + +Useful tool +~~~~~~~~~~~ +POSTMAN collection that can be used to simulate all inter process queries : https://www.getpostman.com/collections/878061d291f9efe55463 +To be able to use this postman collection, you may need to expose some ports that are not exposed in OOM by default. +These commands may help for exposing the ports: + +:: + + kubectl port-forward service/cds-blueprints-processor-http --address 0.0.0.0 32749:8080 -n onap & + kubectl port-forward service/so-catalog-db-adapter --address 0.0.0.0 30845:8082 -n onap & + kubectl port-forward service/so-request-db-adapter --address 0.0.0.0 32223:8083 -n onap & + +OOM Installation +~~~~~~~~~~~~~~~~ +Before doing the OOM installation, take care to the following steps: + +Set the right Openstack values for Robot and SO +=============================================== + +The config for robot must be set in an OOM override file before the OOM installation, this will initialize the robot framework & SO with all the required openstack info. +A section like that is required in that override file + +:: + + robot: + enabled: true + flavor: small + appcUsername: "appc@appc.onap.org" + appcPassword: "demo123456!" + openStackKeyStoneUrl: "http://10.12.25.2:5000" + openStackKeystoneAPIVersion: "v3" + openStackPublicNetId: "5771462c-9582-421c-b2dc-ee6a04ec9bde" + openStackTenantId: "c9ef9a6345b440b7a96d906a0f48c6b1" + openStackUserName: "openstack_user" + openStackUserDomain: "default" + openStackProjectName: "CLAMP" + ubuntu14Image: "trusty-server-cloudimg-amd64-disk1" + ubuntu16Image: "xenial-server-cloudimg-amd64-disk1" + openStackPrivateNetCidr: "10.0.0.0/16" + openStackPrivateNetId: "fd05c1ab-3f43-4f6f-8a8c-76aee04ef293" + openStackPrivateSubnetId: "fd05c1ab-3f43-4f6f-8a8c-76aee04ef293" + openStackSecurityGroup: "f05e9cbf-d40f-4d1f-9f91-d673ba591a3a" + openStackOamNetworkCidrPrefix: "10.0" + dcaeCollectorIp: "10.12.6.10" + vnfPubKey: "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDKXDgoo3+WOqcUG8/5uUbk81+yczgwC4Y8ywTmuQqbNxlY1oQ0YxdMUqUnhitSXs5S/yRuAVOYHwGg2mCs20oAINrP+mxBI544AMIb9itPjCtgqtE2EWo6MmnFGbHB4Sx3XioE7F4VPsh7japsIwzOjbrQe+Mua1TGQ5d4nfEOQaaglXLLPFfuc7WbhbJbK6Q7rHqZfRcOwAMXgDoBqlyqKeiKwnumddo2RyNT8ljYmvB6buz7KnMinzo7qB0uktVT05FH9Rg0CTWH5norlG5qXgP2aukL0gk1ph8iAt7uYLf1ktp+LJI2gaF6L0/qli9EmVCSLr1uJ38Q8CBflhkh" + demoArtifactsVersion: "1.6.0" + demoArtifactsRepoUrl: "https://nexus.onap.org/content/repositories/releases" + scriptVersion: "1.6.0" + nfsIpAddress: "10.12.6.10" + config: + openStackEncryptedPasswordHere: "e10c86aa13e692020233d18f0ef6d527" + openStackSoEncryptedPassword: "1DD1B3B4477FBAFAFEA617C575639C6F09E95446B5AE1F46C72B8FD960219ABB0DBA997790FCBB12" + so: + enabled: true + so-catalog-db-adapter: + config: + openStackUserName: "opesntack_user" + openStackKeyStoneUrl: "http://10.12.25.2:5000/v3" + openStackEncryptedPasswordHere: "1DD1B3B4477FBAFAFEA617C575639C6F09E95446B5AE1F46C72B8FD960219ABB0DBA997790FCBB12" + openStackKeystoneVersion: "KEYSTONE_V3" + +The values that must be changed according to your lab are all "openStack******" parameters + dcaeCollectorIp + nfsIpAddress + +**Generating SO Encrypted Password:** + +The SO Encrypted Password uses a java based encryption utility since the +Java encryption library is not easy to integrate with openssl/python that +Robot uses in Dublin and upper versions. + +.. note:: + To generate SO ``openStackEncryptedPasswordHere`` and ``openStackSoEncryptedPassword`` + ensure `default-jdk` is installed:: + + apt-get update; apt-get install default-jdk + + Then execute (on oom repository):: + + SO_ENCRYPTION_KEY=`cat ~/oom/kubernetes/so/resources/config/mso/encryption.key` + OS_PASSWORD=XXXX_OS_CLEARTESTPASSWORD_XXXX + + git clone http://gerrit.onap.org/r/integration + cd integration/deployment/heat/onap-rke/scripts + + javac Crypto.java + java Crypto "$OS_PASSWORD" "$SO_ENCRYPTION_KEY" + +**Update the OpenStack parameters:** + +There are assumptions in the demonstration VNF Heat templates about the +networking available in the environment. To get the most value out of these +templates and the automation that can help confirm the setup is correct, please +observe the following constraints. + + +``openStackPublicNetId:`` + This network should allow Heat templates to add interfaces. + This need not be an external network, floating IPs can be assigned to the + ports on the VMs that are created by the heat template but its important that + neutron allow ports to be created on them. + +``openStackPrivateNetCidr: "10.0.0.0/16"`` + This ip address block is used to assign OA&M addresses on VNFs to allow ONAP + connectivity. The demonstration Heat templates assume that 10.0 prefix can be + used by the VNFs and the demonstration ip addressing plan embodied in the + preload template prevent conflicts when instantiating the various VNFs. If + you need to change this, you will need to modify the preload data in the + Robot Helm chart like integration_preload_parameters.py and the + demo/heat/preload_data in the Robot container. The size of the CIDR should + be sufficient for ONAP and the VMs you expect to create. + +``openStackOamNetworkCidrPrefix: "10.0"`` + This ip prefix mush match the openStackPrivateNetCidr and is a helper + variable to some of the Robot scripts for demonstration. A production + deployment need not worry about this setting but for the demonstration VNFs + the ip asssignment strategy assumes 10.0 ip prefix. + +**Generating ROBOT Encrypted Password:** + +The Robot encrypted Password uses the same encryption.key as SO but an +openssl algorithm that works with the python based Robot Framework. + +.. note:: + To generate Robot ``openStackEncryptedPasswordHere`` call on oom respository:: + + cd so/resources/config/mso/ + /oom/kubernetes/so/resources/config/mso# echo -n "<openstack tenant password>" | openssl aes-128-ecb -e -K `cat encryption.key` -nosalt | xxd -c 256 -p`` + +Initialize the Customer and Owning entities +=========================================== + +The robot script can be helpful to initialize the customer and owning entity that +will be used later to instantiate the VNF (PART 2 - Scale Out Use Case Instantiation) + +:: + + In the oom_folder/kubernetes/robot/ execute the following command: + ./demo-k8s.sh onap init_customer + +If this command is unsuccessful it means that the parameters provided to the OOM installation were not correct. + +- Verify and Get the tenant/owning entity/cloud-regions defined in AAI by Robot script: + These values will be required by the POSTMAN collection when instantiating the Service/vnf ... + +To get them some POSTMAN collection queries are useful to use: + +- GET "AAI Owning Entities" +- GET "AAI Cloud-regions" +- GET "AAI Cloud-regions/tenant" Description ~~~~~~~~~~~ -The scale out use case uses a VNF composed of three virtual functions. A traffic generator (vPacketGen), a load balancer (vLB), and a DNS (vDNS). Communication between the vPacketGen and the vLB, and the vLB and the vDNS occurs via two separate private networks. In addition, all virtual functions have an interface to the ONAP OAM private network, as shown in the topology below. + +The scale out use case uses a VNF composed of three virtual functions. A traffic +generator (vPacketGen), a load balancer (vLB), and a DNS (vDNS). Communication +between the vPacketGen and the vLB, and the vLB and the vDNS occurs via two +separate private networks. In addition, all virtual functions have an interface +to the ONAP OAM private network, as shown in the topology below. .. figure:: files/scaleout/topology.png :align: center -The vPacketGen issues DNS lookup queries that reach the DNS server via the vLB. vDNS replies reach the packet generator via the vLB as well. The vLB reports the average amount of traffic per vDNS instances over a given time interval (e.g. 10 seconds) to the DCAE collector via the ONAP OAM private network. +The vPacketGen issues DNS lookup queries that reach the DNS server via the vLB. +vDNS replies reach the packet generator via the vLB as well. The vLB reports the +average amount of traffic per vDNS instances over a given time interval (e.g. 10 +seconds) to the DCAE collector via the ONAP OAM private network. -To run the use case, make sure that the security group in OpenStack has ingress/egress entries for protocol 47 (GRE). Users can test the VNF by running DNS queries from the vPakcketGen: +To run the use case, make sure that the security group in OpenStack has +ingress/egress entries for protocol 47 (GRE). Users can test the VNF by running +DNS queries from the vPakcketGen: :: @@ -61,7 +225,14 @@ The output below means that the vLB has been set up correctly, has forwarded the The Scale Out Use Case ~~~~~~~~~~~~~~~~~~~~~~ -The Scale Out use case shows how users/network operators can add Virtual Network Function Components (VNFCs) as part of a VF Module that has been instantiated in the Service model, in order to increase capacity of the network. ONAP Frankfurt release supports scale out with manual trigger by directly calling SO APIs and closed-loop-enabled automation from Policy. For Frankfurt, the APPC controller is used to demonstrate post-scaling VNF reconfiguration operations. APPC can handle different VNF types, not only the VNF described in this document. + +The Scale Out use case shows how users/network operators can add Virtual Network +Function Components (VNFCs) as part of a VF Module that has been instantiated in +the Service model, in order to increase capacity of the network. ONAP Frankfurt +release supports scale out with manual trigger by directly calling SO APIs and +closed-loop-enabled automation from Policy. For Frankfurt, the APPC controller is +used to demonstrate post-scaling VNF reconfiguration operations. APPC can handle +different VNF types, not only the VNF described in this document. The figure below shows all the interactions that take place during scale out operations. @@ -74,37 +245,87 @@ There are four different message flows: - Red: Closed-loop enabled scale out. - Black: Orchestration and VNF lifecycle management (LCM) operations. -The numbers in the figure represent the sequence of steps within a given flow. Note that interactions between the components in the picture and AAI, SDNC, and DMaaP are not shown for clarity's sake. - -Scale out with manual trigger (green flow) and closed-loop-enabled scale out (red flow) are mutually exclusive. When the manual trigger is used, VID directly triggers the appropriate workflow in SO (step 1 of the green flow in the figure above). See Section 4 for more details. - -When closed-loop enabled scale out is used, Policy triggers the SO workflow. The closed loop starts with the vLB periodically reporting telemetry about traffic patterns to the VES collector in DCAE (step 1 of the red flow). When the amount of traffic exceeds a given threshold (which the user defines during closed loop creation in CLAMP - see Section 1-4), DCAE notifies Policy (step 2), which in turn triggers the appropriate action. For this use case, the action is contacting SO to augment resource capacity in the network (step 3). - -At high level, once SO receives a call for scale out actions, it first creates a new VF module (step 1 of the black flow), then calls APPC to trigger some LCM actions (step 2). APPC runs VNF health check and configuration scale out as part of LCM actions (step 3). At this time, the VNF health check only reports the health status of the vLB, while the configuration scale out operation adds a new vDNS instance to the vLB internal state. As a result of configuration scale out, the vLB opens a connection towards the new vDNS instance. +The numbers in the figure represent the sequence of steps within a given flow. +Note that interactions between the components in the picture and AAI, SDNC, and +DMaaP are not shown for clarity's sake. + +Scale out with manual trigger (green flow) and closed-loop-enabled scale out +(red flow) are mutually exclusive. When the manual trigger is used, VID directly +triggers the appropriate workflow in SO (step 1 of the green flow in the figure +above). See Section 4 for more details. + +When closed-loop enabled scale out is used, Policy triggers the SO workflow. +The closed loop starts with the vLB periodically reporting telemetry about traffic +patterns to the VES collector in DCAE (step 1 of the red flow). When the amount +of traffic exceeds a given threshold (which the user defines during closed loop +creation in CLAMP - see Section 1-4), DCAE notifies Policy (step 2), which in turn +triggers the appropriate action. For this use case, the action is contacting SO to +augment resource capacity in the network (step 3). + +At high level, once SO receives a call for scale out actions, it first creates a +new VF module (step 1 of the black flow), then calls APPC to trigger some LCM +actions (step 2). APPC runs VNF health check and configuration scale out as part +of LCM actions (step 3). At this time, the VNF health check only reports the +health status of the vLB, while the configuration scale out operation adds a new +vDNS instance to the vLB internal state. As a result of configuration scale out, +the vLB opens a connection towards the new vDNS instance. At deeper level, the SO workflow works as depicted below: .. figure:: files/scaleout/so-blocks.png :align: center -SO first contacts APPC to run VNF health check and proceeds on to the next block of the workflow only if the vLB is healthy (not shown in the previous figure for simplicity's sake). Then, SO assigns resources, instantiates, and activates the new VF module. Finally, SO calls APPC again for configuration scale out and VNF health check. The VNF health check at the end of the workflow validates that the vLB health status hasn't been negatively affected by the scale out operation. +SO first contacts APPC to run VNF health check and proceeds on to the next block +of the workflow only if the vLB is healthy (not shown in the previous figure for +simplicity's sake). Then, SO assigns resources, instantiates, and activates the +new VF module. Finally, SO calls APPC again for configuration scale out and VNF +health check. The VNF health check at the end of the workflow validates that the +vLB health status hasn't been negatively affected by the scale out operation. PART 1 - Service Definition and Onboarding ------------------------------------------ + This use-case requires operations on several ONAP components to perform service definition and onboarding. +1-1 VNF Configuration Modeling and Upload with CDS (Recommended way) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -1-1 VNF Configuration Modeling and Upload with CDS -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Since Dublin, the scale out use case integrates with the Controller Design Studio (CDS) ONAP component to automate the generation of cloud configuration at VNF instantiation time. The user interested in running the use case only with manual preload can skip this section and start from Section 1-2. The description of the use case with manual preload is provided in Section5. Users can model this configuration at VNF design time and onboard the blueprint to CDS via the CDS GUI. The blueprint includes naming policies and network configuration details (e.g. IP address families, network names, etc.) that CDS will use during VNF instantiation to generate resource names and assign network configuration to VMs through the cloud orchestrator. Please look at the CDS documentation for details about how to create configuration models, blueprints, and use the CDS tool: https://wiki.onap.org/display/DW/Modeling+Concepts. For running the use case, users can use the standard model package that CDS provides out of the box, which can be found here: https://wiki.onap.org/pages/viewpage.action?pageId=64007442 +:: + + For the current use case you can also follow these steps (Do not use the SDC flow to deploy the CBA when importing a VSP, this is not going to work anymore since Guilin): + 1. You must first bootstrap CDS by using the query in the POSTMAN collection query named POST "CDS Bootstrap" + 2. You must upload the attached CBA by using the POSTMAN collection named POST "CDS Save without Validation", the CBA zip file can be attached in the POSTMAN query + Controller Blueprint Archive (to use with CDS) : https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/service-blueprint/vLB_CDS_Kotlin?h=guilin + 3. Create a zip file with the HEAT files located here: https://git.onap.org/demo/tree/heat/vLB_CDS?h=guilin + 4. Create the VSP & Service in the SDC onboarding and SDC Catalog + Distribute the service + To know the right values that must be set in the SDC Service properties assignment you must open the CBA zip and look at the TOSCA-Metadata/TOSCA.meta file + This file looks like that: + TOSCA-Meta-File-Version: 1.0.0 + CSAR-Version: 1.0 + Created-By: Seaudi, Abdelmuhaimen <abdelmuhaimen.seaudi@orange.com> + Entry-Definitions: Definitions/vLB_CDS.json + Template-Tags: vLB_CDS + Template-Name: vLB_CDS + Template-Version: 1.0.0 + Template-Type: DEFAULT + + - The sdnc_model_version is the Template-Version + - The sdnc_model_name is the Template-Name + - The sdnc_artifact_name is the prefix of the file you want to use in the Templates folder, in our CBA example it's vnf (that is supposed to reference the /Templates/vnf-mapping.json file) + + Follow this guide for the VSP onboarding + service creation + properties assignment + distribution part (just skip the CBA attachment part as the CBA should have been pushed manually with the REST command): https://wiki.onap.org/pages/viewpage.action?pageId=64007442 + + Note that in case of issues with the AAI distribution, this may help : https://jira.onap.org/browse/AAI-1759 1-2 VNF Onboarding and Service Creation with SDC ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + Once the configuration blueprint is uploaded to CDS, users can define and onboard a service using SDC. SDC requires users to onboard a VNF descriptor that contains the definition of all the resources (private networks, compute nodes, keys, etc.) with their parameters that compose a VNF. The VNF used to demonstrate the scale out use case supports Heat templates as VNF descriptor, and hence requires OpenStack as cloud layer. Users can use the Heat templates linked at the top of the page to create a zip file that can be uploaded to SDC during service creation. To create a zip file, the user must be in the same folder that contains the Heat templates and the Manifest file that describes the content of the package. To create a zip file from command line, type: :: @@ -139,7 +360,7 @@ To upload a DCAE blueprint, from the "Composition" tab in the service menu, sele .. figure:: files/scaleout/1.png :align: center -Upload the DCAE blueprint linked at the top of the page using the pop-up window. +Upload the DCAE blueprint (choose the one depending on your ONAP release, as the orginal TCA was depecrated in Guilin a new one is available to use) linked at the top of the page using the pop-up window. .. figure:: files/scaleout/2.png :align: center @@ -162,10 +383,11 @@ This VNF only supports scaling the vDNS, so users should select the vDNS module At this point, users can complete the service creation in SDC by testing, accepting, and distributing the Service Models as described in the SDC user manual. - 1-3 Deploy Naming Policy ~~~~~~~~~~~~~~~~~~~~~~~~ + This step is only required if CDS is used. +Note that in Guilin, the default naming policy is already deployed in policy so this step is optional In order to instantiate the VNF using CDS features, users need to deploy the naming policy that CDS uses for resource name generation to the Policy Engine. User can copy and run the script at the top of the page from any ONAP pod, for example Robot or Drools. The script uses the Policy endpoint defined in the Kubernetes domain, so the execution has to be triggered from some pod in the Kubernetes space. @@ -175,9 +397,98 @@ In order to instantiate the VNF using CDS features, users need to deploy the nam ./push_naming_policy.sh + 1-4 Closed Loop Design with CLAMP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This step is only required if closed loop is used. + +This step is only required if closed loop is used, for manual scaleout this section can be skipped. + +Here are Json examples that can be copy pasted in each policy configuration by clicking on the button EDIT JSON, just replace the value "LOOP_test_vLB_CDS" by your loop ID: +For TCA config: +:: + + { + "tca.policy": { + "domain": "measurementsForVfScaling", + "metricsPerEventName": [ + { + "policyScope": "DCAE", + "thresholds": [ + { + "version": "1.0.2", + "severity": "MAJOR", + "thresholdValue": 200, + "closedLoopEventStatus": "ONSET", + "closedLoopControlName": "LOOP_test_vLB_CDS", + "direction": "LESS_OR_EQUAL", + "fieldPath": "$.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedTotalPacketsDelta" + } + ], + "eventName": "vLoadBalancer", + "policyVersion": "v0.0.1", + "controlLoopSchemaType": "VM", + "policyName": "DCAE.Config_tca-hi-lo" + } + ] + } + } + +For Drools config: + +:: + + { + "abatement": false, + "operations": [ + { + "failure_retries": "final_failure_retries", + "id": "policy-1-vfmodule-create", + "failure_timeout": "final_failure_timeout", + "failure": "final_failure", + "operation": { + "payload": { + "requestParameters": "{\"usePreload\":false,\"userParams\":[]}", + "configurationParameters": "[{\"ip-addr\":\"$.vf-module-topology.vf-module-parameters.param[16].value\",\"oam-ip-addr\":\"$.vf-module-topology.vf-module-parameters.param[30].value\"}]" + }, + "target": { + "entityIds": { + "resourceID": "Vlbcds..vdns..module-3", + "modelInvariantId": "e95a2949-8ba5-433d-a88f-587a6244b4ea", + "modelVersionId": "4a6ceddc-147e-471c-ae6f-907a0df76040", + "modelName": "Vlbcds..vdns..module-3", + "modelVersion": "1", + "modelCustomizationId": "7806ed67-a826-4b0e-b474-9ca4fa052a10" + }, + "targetType": "VFMODULE" + }, + "actor": "SO", + "operation": "VF Module Create" + }, + "failure_guard": "final_failure_guard", + "retries": 1, + "timeout": 300, + "failure_exception": "final_failure_exception", + "description": "test", + "success": "final_success" + } + ], + "trigger": "policy-1-vfmodule-create", + "timeout": 650, + "id": "LOOP_test_vLB_CDS" + } + +For Frequency Limiter config: + +:: + + { + "id": "LOOP_test_vLB_CDS", + "actor": "SO", + "operation": "VF Module Create", + "limit": 1, + "timeWindow": 10, + "timeUnits": "minute" + } Once the service model is distributed, users can design the closed loop from CLAMP, using the GUI at https://clamp.api.simpledemo.onap.org:30258 @@ -283,6 +594,7 @@ At this point, the closed loop is deployed to Policy Engine and DCAE, and a new 1-5 Creating a VNF Template with CDT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + Before running scale out use case, the users need to create a VNF template using the Controller Design Tool (CDT), a design-time tool that allows users to create and on-board VNF templates into APPC. The template describes which control operation can be executed against the VNF (e.g. scale out, health check, modify configuration, etc.), the protocols that the VNF supports, port numbers, VNF APIs, and credentials for authentication. Being VNF agnostic, APPC uses these templates to "learn" about specific VNFs and the supported operations. CDT requires two input: @@ -349,6 +661,8 @@ To create the VNF template in CDT, the following steps are required: - Click "Reference Data" Tab - Click "Save All to APPC" +Note, if a user gets an error when saving to Appc (cannot connect to AppC network), he should open a browser to http://ANY_K8S_IP:30211 to accept AppC proxy certificate + For health check operation, we just need to specify the protocol, the port number and username of the VNF (REST, 8183, and "admin" respectively, in the case of vLB/vDNS) and the API. For the vLB/vDNS, the API is: :: @@ -366,6 +680,7 @@ At this time, CDT doesn't allow users to provide VNF password from the GUI. To u 1-6 Setting the Controller Type in SO Database ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + Users need to specify which controller to use for the scale out use case. For Dublin, the supported controller is APPC. Users need to create an association between the controller and the VNF type in the SO database. To do so: @@ -377,7 +692,7 @@ To do so: mysql -ucataloguser -pcatalog123 -- Use catalogdb databalse +- Use catalogdb database :: @@ -395,6 +710,7 @@ SO has a default entry for VNF type "vLoadBalancerMS/vLoadBalancerMS 0" 1-7 Determining VNF reconfiguration parameters ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + The post scale out VNF reconfiguration is VNF-independent but the parameters used for VNF reconfiguration depend on the specific use case. For example, the vLB-vDNS-vPacketGenerator VNF described in this documentation use the vLB as "anchor" point. The vLB maintains the state of the VNF, which, for this use case is the list of active vDNS instances. After creating a new vDNS instance, the vLB needs to know the IP addresses (of the internal private network and management network) of the new vDNS. The reconfiguration action is executed by APPC, which receives those IP addresses from SO during the scale out workflow execution. Note that different VNFs may have different reconfiguration actions. A parameter resolution is expressed as JSON path to the SDNC VF module topology parameter array. For each reconfiguration parameter, the user has to specify the array location that contains the corresponding value (IP address in the specific case). For example, the "configurationParameters" section of the input request to SO during scale out with manual trigger (see Section 4) contains the resolution path to "ip-addr" and "oam-ip-addr" parameters used by the VNF. :: @@ -896,7 +1212,30 @@ In future releases, we plan to leverage CDS to model post scaling VNF reconfigur PART 2 - Scale Out Use Case Instantiation ----------------------------------------- -This step is only required if CDS is used. + +Manual queries with POSTMAN +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This step is only required if CDS is used, otherwise you can use VID to instantiate the service and the VNF. +Note that the POSTMAN collection linked at the top of this page, does provide some level of automatic scripting that will automatically get values between requests and provision the following queries + +You must enter in the postman config different variables: +- "k8s" -> The k8s loadBalancer cluster node +- "cds-service-model" -> The SDC service name distributed +- "cds-instance-name" -> A name of your choice for the vnf instance (This must be changed each time you launch the instantiation) + +These useful requests are: +CDS#1 - SDC Catalog Service -> This gets the Sdc service and provision some variables +CDS#2 - SO Catalog DB Service VNFs - CDS -> This gets info in SO and provision some variables for the instantiation +CDS#3 - SO Self-Serve Service Assign & Activate -> This starts the Service/vnf instantiation +Open the body and replace the values like tenantId, Owning entity, region, and all the openstack values everywhere in the payload + +Note that you may have to add "onap_private_net_cidr":"10.0.0.0/16" in the "instanceParams" array depending of your openstack network configuration. + +CDS#4 - SO infra Active Request -> Used to get the status of the previous query + +Manual queries without POSTMAN +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GET information from SDC catalogdb @@ -1159,6 +1498,7 @@ PART 3 - Post Instantiation Operations 3-1 Post Instantiation VNF configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CDS executes post-instantiation VNF configuration if the "skip-post-instantiation" flag in the SDC service model is set to false, which is the default behavior. Manual post-instantiation configuration is necessary if the "skip-post-instantiation" flag in the service model is set to true or if the VNF is instantiated using the preload approach, which doesn't include CDS. Regardless, this step is NOT required during scale out operations, as VNF reconfiguration will be triggered by SO and executed by APPC. If VNF post instantiation is executed manually, in order to change the state of the vLB the users should run the following REST call, replacing the IP addresses in the VNF endpoint and JSON object to match the private IP addresses of their vDNS instance: @@ -1186,6 +1526,7 @@ At this point, the VNF is fully set up. 3-2 Updating AAI with VNF resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + To allow automated scale out via closed loop, the users need to inventory the VNF resources in AAI. This is done by running the heatbridge python script in /root/oom/kubernetes/robot in the Rancher VM in the Kubernetes cluster: :: @@ -1198,7 +1539,25 @@ Note that "vlb_onap_private_ip_0" used in the heatbridge call is the actual para PART 4 - Triggering Scale Out Manually -------------------------------------- -For scale out with manual trigger, VID is not supported at this time. Users can run the use case by directly calling SO APIs: +For scale out with manual trigger, VID is not supported at this time. + +Manual queries with POSTMAN +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Note that the POSTMAN collection linked at the top of this page, does provide some level of automatic scripting that will automatically get values between requests and provision the following queries + +You must enter in the postman config different variables: +- "k8s" -> The k8s loadBalancer cluster node +- "cds-service-model" -> The SDC service name distributed +- "cds-instance-name" -> A name of your choice for the vnf instance (This must be changed each time you launch the instantiation) + +CDS#5 - SO ScaleOut -> This will initiate a Scaleout manually +CDS#7 - SO ScaleIn -> This will initiate a ScaleIn manually + +Manual queries without POSTMAN +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Users can run the use case by directly calling SO APIs: :: @@ -1752,6 +2111,7 @@ Module-1 Preload Module-2 Preload ~~~~~~~~~~~~~~~~ + :: @@ -2068,7 +2428,8 @@ To instantiate VF modules, please refer to this wiki page: https://wiki.onap.org PART 6 - Known Issues and Resolutions ------------------------------------- -1) When running closed loop-enabled scale out, the closed loop designed in CLAMP conflicts with the default closed loop defined for the old vLB/vDNS use case + + 1) When running closed loop-enabled scale out, the closed loop designed in CLAMP conflicts with the default closed loop defined for the old vLB/vDNS use case Resolution: Change TCA configuration for the old vLB/vDNS use case @@ -2076,3 +2437,5 @@ Resolution: Change TCA configuration for the old vLB/vDNS use case - Change "eventName" in the vLB default policy to something different, for example "vLB" instead of the default value "vLoadBalancer" - Change "subscriberConsumerGroup" in the TCA configuration to something different, for example "OpenDCAE-c13" instead of the default value "OpenDCAE-c12" - Click "UPDATE" to upload the new TCA configuration + +2) During Guilin testing, it has been noticed that there is an issue between SO and APPC for Healthcheck queries, this does not prevent the use case to proceed but limit APPC capabilities diff --git a/docs/docs_usecases.rst b/docs/docs_usecases.rst index ff5e18bff..a8efb0d63 100644 --- a/docs/docs_usecases.rst +++ b/docs/docs_usecases.rst @@ -3,84 +3,9 @@ .. _docs_usecases: -Verified Use Cases and Functional Requirements ----------------------------------------------- +:orphan: -Description -~~~~~~~~~~~ -This session includes use cases and functional requirements which have been -officially verified in Frankfurt release by the ONAP community. +.. toctree:: + :maxdepth: 1 -For each use case or functional requirement, you can find contact names and a -link to the associated documentation. - -This documentation deals with - - 1. What has been implemented - 2. Step by step instructions to deploy and execute the tests, including the - links to download the related assets and resources - 3. Known issues and workarounds - -The final testing status can be found at `Frankfurt Release Integration Testing -Status <https://wiki.onap.org/display/DW/2%3A+Frankfurt+Release+Integration+Testing+Status>`_ - -31 use cases/functional requirements have been considered for the Frankfurt release. - -Use cases -~~~~~~~~~ - -.. csv-table:: use case table - :file: usecases.csv - :widths: 60,20,20 - :header-rows: 1 - -Functional Requirements -~~~~~~~~~~~~~~~~~~~~~~~ - -.. csv-table:: functional requirements table - :file: functional-requirements.csv - :widths: 60,20,20 - :header-rows: 1 - -.. csv-table:: 5G functional requirements table - :file: functional-requirements-5g.csv - :widths: 60,20,20 - :header-rows: 1 - -Automated Use Cases -~~~~~~~~~~~~~~~~~~~ - -Most of the use cases include some automation through robot or bash scripts. -These scripts are detailed in the documentation. - -Some use cases have been integrated in ONAP gates. It means the tests are run on -each daily or gating CI chain. The goal is to detect any regression as soon as -possible and demonstrate the ability to automate the use cases. - -.. csv-table:: automated use cases table - :file: automated-usecases.csv - :widths: 10,80,10 - :delim: ; - :header-rows: 1 - -The robot scripts can be found in ONAP testsuite repository, an execution -run-time is provided through the robot pod. - -The python onap_tests framework is hosted on -https://gitlab.com/Orange-OpenSource/lfn/onap/onap-tests. Please not that this -framework is valid up to Frankfurk and will be deprecated in Guilin. It will -be replaced by scenarios leveraging python-onapsdk -https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk. - -Deprecated Use Cases -~~~~~~~~~~~~~~~~~~~~ - -The following use cases were included in El Alto or previous release but have -not been tested in Frankfurt, usually due to a lack of resources. -The resources are still available in previous branches, some adaptations may -however be needed for Frankfurt. - -.. csv-table:: deprecated use case table - :file: usecases-deprecated.csv - :widths: 50,20,10,20 - :header-rows: 1 + usecases/deprecated_usecases.rst diff --git a/docs/docs_usecases_release.rst b/docs/docs_usecases_release.rst new file mode 100644 index 000000000..e8f3c401f --- /dev/null +++ b/docs/docs_usecases_release.rst @@ -0,0 +1,34 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 + International License. http://creativecommons.org/licenses/by/4.0 + +.. _docs_usecases_release: + +:orphan: + +Kohn Use Cases and Requirements +=============================== + +Description +----------- + +This session includes use cases and functional requirements which have been +officially verified in Kohn release by the ONAP community. + +For each use case or functional requirement, you can find contact names and a +link to the associated documentation. + +This documentation deals with + + 1. What has been implemented + 2. Step by step instructions to deploy and execute the tests, including the + links to download the related assets and resources + 3. Known issues and workarounds + +.. toctree:: + :maxdepth: 1 + + usecases/release_usecases.rst + usecases/release_automated_usecases.rst + usecases/release_requirements.rst + usecases/release_non_functional_requirements.rst + usecases/deprecated_usecases.rst diff --git a/docs/docs_vCPE.rst b/docs/docs_vCPE.rst index a0550cc22..6a8e2c536 100644 --- a/docs/docs_vCPE.rst +++ b/docs/docs_vCPE.rst @@ -4,8 +4,10 @@ .. _docs_vcpe: +:orphan: + vCPE Use Case ----------------------------- +------------- Description ~~~~~~~~~~~ diff --git a/docs/docs_vCPE_tosca_local.rst b/docs/docs_vCPE_tosca_local.rst index 44cdf6dcf..8b903adb7 100644 --- a/docs/docs_vCPE_tosca_local.rst +++ b/docs/docs_vCPE_tosca_local.rst @@ -4,6 +4,8 @@ .. _docs_vcpe_tosca_local: +:orphan: + vCPE Tosca Local Mode Use Case ------------------------------ @@ -24,7 +26,7 @@ How to Use The use case has been automated by vcpe_tosca_test scripts. The followings are the main steps to run the use case in Integration lab environment: 1) Install ONAP CLI environment, open_cli_product is onap-dublin. - + Use https://git.onap.org/integration/tree/test/vcpe_tosca/local/scripts/install-alpine.sh to install ONAP CLI. 2) Prepare openstack test environment. @@ -83,14 +85,17 @@ The use case has been automated by vcpe_tosca_test scripts. The followings are t :: + "open_cli_product": set to CLI product you installed, onap-dublin is OK for this test. "open_cli_home": set to the oclip home path, "aai_url": set to msb ip and port you used, "msb_url": set to msb ip and port you used, "multicloud_url": set to msb ip and port you used, + "complex_name": set to any complex name you want to use, the name must be unique + "cloud_region_data": { "RegionOne":(update to your Region name) { - "cloud-region-version": the cloud region version of your Cloud region, + "cloud-region-version": the cloud region version of your Cloud region, you can keep "titanium_cloud" "esr-system-info-id": "1111ce1f-aa78-4ebf-8d6f-4b62773e9b01", "service-url": the ip change to your openstack ip address, "user-name": the user name you created on openstack, @@ -105,22 +110,47 @@ The use case has been automated by vcpe_tosca_test scripts. The followings are t "system-status": "active" } } + "cloud-owner": set to any cloud name you want to use, , the name must be unique + "service_name": set to any service name you want to use, the name must be unique + "customer_name": set to any customer name you want to use, the name must be unique + "subscriber_name": set to any subscriber name you want to use, the name must be unique + "vfc-url": set to msb ip and port you used, "vnfs": { - "vgw": { - "path": "vgw.csar", set to your vnf csar file path - "key": "key2", - "value": "value2" - } - }, - "ns": { + "vgw": { + "path": "/csar/vgw.csar", set to you vgw csar file path + "key": "key2", + "value": "value2" + }, + "infra": { + "path": "/csar/infra.csar", set to you infra csar file path + "key": "key2", + "value": "value2" + }, + "vbng": { + "path": "/csar/vbng.csar", set to you vbng csar file path + "key": "key2", + "value": "value2" + }, + "vbrgemu": { + "path": "/csar/vbrgemu.csar", set to you vbrgemu csar file path + "key": "key2", + "value": "value2" + }, + "vgmux": { + "path": "/csar/vgmux.csar", set to you vgmux csar file path + "key": "key2", + "value": "value2" + } + }, + "ns": { "key": "key1", "value": "value1", "path": "ns_vgw.csar", set to you ns csar file path "name": "vcpe11" - }, + }, "location": "VCPE22_RegionOne", set to CloudOwner_CloudRegion - "vnfm_params": { + "vnfm_params": { "GVNFMDRIVER": { "type": "gvnfmdriver", "vendor": "vfc", @@ -130,8 +160,8 @@ The use case has been automated by vcpe_tosca_test scripts. The followings are t "user-name": "admin", "user-password": "admin", "vnfm-version": "v1.0" - } - } + } + } 4) The vnf csar file include Infra, vGW, vBNG, vBRGEMU and vGMUX, and the ns csar file is ns. https://git.onap.org/integration/tree/test/vcpe_tosca/local/csar @@ -162,9 +192,11 @@ The use case has been automated by vcpe_tosca_test scripts. The followings are t Note ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -1) You should create an image named image before running the test script, the name must be the same with image which is defined in vnf csar file. +1) You must authorize admin to vcpe_case when managing project members in openstack. + +2) You should create an image named image before running the test script, the name must be the same with image which is defined in vnf csar file. -2) You should install ONAP CLI before running the script. +3) You should install ONAP CLI before running the script. Known Issues and Workaround diff --git a/docs/docs_vCPE_with_Tosca_VNF.rst b/docs/docs_vCPE_with_Tosca_VNF.rst index 6f9bf8ba0..3343bdf9f 100644 --- a/docs/docs_vCPE_with_Tosca_VNF.rst +++ b/docs/docs_vCPE_with_Tosca_VNF.rst @@ -1,7 +1,9 @@ .. _docs_vcpe_tosca: +:orphan: + vCPE with Tosca VNF ----------------------------- +------------------- VNF Packages and NS Packages ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -19,8 +21,8 @@ How to Use ~~~~~~~~~~ -Configuration: -~~~~~~~~~~~~~~ +Configuration +~~~~~~~~~~~~~ 1) VIM Configuration Prepare openstack test environment. @@ -51,15 +53,15 @@ Configuration: .. image:: files/vcpe_tosca/vnfm.png -Design Time: -~~~~~~~~~~~~ +Design Time +~~~~~~~~~~~ 1) We put the real ETSI aligned package as package artifact. 2) When design Network service in SDC, should assign "gvnfmdriver" as the value of nf_type in Properties Assignment. so that VF-C can know will use gvnfm to manage VNF life cycle. .. image:: files/vcpe_tosca/sdc.png -Run Time: -~~~~~~~~~ +Run Time +~~~~~~~~ 1) First onboard VNF/NS package from SDC to modeling etsicatalog in sequence. 2) Trigger the NS operation via UUI guide diff --git a/docs/docs_vFWDT.rst b/docs/docs_vFWDT.rst index ebf9e8985..0c13886d2 100644 --- a/docs/docs_vFWDT.rst +++ b/docs/docs_vFWDT.rst @@ -3,12 +3,11 @@ .. _docs_vfw_traffic: -.. contents:: - :depth: 3 -.. +:orphan: vFW In-Place Software Upgrade with Traffic Distribution Use Case ---------------------------------------------------------------- + Description ~~~~~~~~~~~ @@ -488,7 +487,7 @@ Configuration of VNF in the APPC CDT tool .. note:: Automated procedure can be found at the end of the section -Following steps aim to configure DistributeTraffic LCM action for our vPKG and vFW-SINK VNFs in APPC CDT tool. +Following steps aim to configure DistributeTraffic LCM action for our vPKG and vFW-SINK VNFs in APPC CDT tool. 1. Enter the Controller Design Tool portal @@ -799,7 +798,7 @@ the execution of APPC LCM actions with configuration resolved before by Optimiza Workflow Execution ~~~~~~~~~~~~~~~~~~ -In order to run workflows execute following commands from the vFWDT tutorial directory `Preparation of Workflow Script Environment`_ on Rancher server. +In order to run workflows execute following commands from the vFWDT tutorial directory `Preparation of Workflow Script Environment`_ on Rancher server. For Traffic Distribution workflow run @@ -839,8 +838,8 @@ The order of executed LCM actions for In-Place Software Upgrade with Traffic Dis 5. DistributeTraffic on vPKG VM - ansible playbook reconfigures vPKG in order to send traffic to destination specified before by OOF. 6. DistributeTrafficCheck on vFW-1 VM - ansible playbook checks if traffic is not present on vFW from which traffic should be migrated out. If traffic is still present after 30 seconds playbook fails 7. DistributeTrafficCheck on vFW-2 VM - ansible playbook checks if traffic is present on vFW from which traffic should be migrated out. If traffic is still not present after 30 seconds playbook fails -8. UpgradeSoftware on vFW-1 VM - ansible playbook modifies the software on the vFW instance and sets the version of the software to the specified one in the request -9. UpgradePostCheck on vFW-1 VM - ansible playbook checks if the software of vFW is the same like the one specified in the workflows input. +8. UpgradeSoftware on vFW-1 VM - ansible playbook modifies the software on the vFW instance and sets the version of the software to the specified one in the request +9. UpgradePostCheck on vFW-1 VM - ansible playbook checks if the software of vFW is the same like the one specified in the workflows input. 10. DistributeTraffic on vPKG VM - ansible playbook reconfigures vPKG in order to send traffic to destination specified before by OOF (reverse configuration). 11. DistributeTrafficCheck on vFW-2 VM - ansible playbook checks if traffic is not present on vFW from which traffic should be migrated out. If traffic is still present after 30 seconds playbook fails 12. DistributeTrafficCheck on vFW-1 VM - ansible playbook checks if traffic is present on vFW from which traffic should be migrated out. If traffic is still not present after 30 seconds playbook fails diff --git a/docs/docs_vFW_CNF_CDS.rst b/docs/docs_vFW_CNF_CDS.rst index 77b618e5b..5e01df317 100644 --- a/docs/docs_vFW_CNF_CDS.rst +++ b/docs/docs_vFW_CNF_CDS.rst @@ -1,41 +1,45 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 -.. Copyright 2020 ONAP +.. Copyright 2022 ONAP .. _docs_vFW_CNF_CDS: -.. contents:: - :depth: 4 -.. +:orphan: ----------------------- vFirewall CNF Use Case ---------------------- Source files ~~~~~~~~~~~~ - Heat/Helm/CDS models: `vFW_CNF_CDS Model`_ +- Automation Scripts: `vFW_CNF_CDS Automation`_ Description ~~~~~~~~~~~ -This use case is a combination of `vFW CDS Dublin`_ and `vFW EDGEX K8S`_ use cases. The aim is to continue improving Kubernetes based Network Functions (a.k.a CNF) support in ONAP. Use case continues where `vFW EDGEX K8S`_ left and brings CDS support into picture like `vFW CDS Dublin`_ did for the old vFW Use case. Predecessor use case is also documented here `vFW EDGEX K8S In ONAP Wiki`_. - -In a higher level this use case brings only two improvements yet important ones i.e. the ability to instantiate more than single CNF instance of same type (with same Helm package) and ability to embed into singular onboarding package more than one helm package what brings more service design options. +This use case is a combination of `vFW CDS Dublin`_ and `vFW EDGEX K8S`_ use cases and it is continously improved since Frankfurt release. The aim is to continue improving Kubernetes based Network Functions (a.k.a CNF) support in ONAP. Use case continues where `vFW EDGEX K8S`_ left and brings CDS support into picture like `vFW CDS Dublin`_ did for the old vFW Use case. Predecessor use case is also documented here `vFW EDGEX K8S In ONAP Wiki`_. -Following improvements were made in the Use Case or related ONAP components: +This use case shows how to onboard helm packages and to instantiate them with help of ONAP. Following improvements were made in the vFW CNF Use Case: -- Changed vFW Kubernetes Helm charts to support overrides (previously mostly hardcoded values) -- Combined all models (Heat, Helm, CBA) in to same git repo and a creating single onboarding package `vFW_CNF_CDS Model`_ -- Compared to `vFW EDGEX K8S`_ use case **MACRO** workflow in SO is used instead of VNF a'la carte workflow. (this is general requirement to utilize CDS as part of instantiation flow) +- vFW Kubernetes Helm charts support overrides (previously mostly hardcoded values) - SDC accepts Onboarding Package with many helm packages what allows to keep decomposition of service instance similar to `vFW CDS Dublin`_ -- CDS is used to resolve instantiation time parameters (Helm override) - - Ip addresses with IPAM - - Unique names for resources with ONAP naming service -- Multicloud/k8s plugin changed to support identifiers of vf-module concept -- **multicloud/k8s** creates automatically default empty RB profile and profile upload becomes optional for instantiation of CNF -- CDS is used to create **multicloud/k8s profile** as part of instantiation flow (previously manual step) - -Use case does not contain Closed Loop part of the vFW demo. +- Compared to `vFW EDGEX K8S`_ use case **MACRO** workflow in SO is used instead of VNF a'la carte workflow +- No VNF data preloading used, instead resource-assignment feature of CDS is used +- CDS is used to resolve instantiation time parameters (Helm overrides) + * IP addresses with IPAM + * Unique names for resources with ONAP naming service + * CDS is used to create and upload **multicloud/k8s profile** as part of instantiation flow +- Combined all models (Heat, Helm, CBA) in to same git repo and a created single onboarding package `vFW_CNF_CDS Model`_ +- vFW CNF status is monitored prior to the completion of the instantiation process. +- It is possible to not only provide overrides for Helm packages but we can modify Helm packages before instantiation or we can modify CNF after its deployment +- Use case does not contain Closed Loop part of the vFW demo. + +All changes to related ONAP components and Use Case can be found in the following tickets: + +- `REQ-182`_ +- `REQ-341`_ +- `REQ-458`_ +- `REQ-627`_ +- `REQ-890`_ The vFW CNF Use Case ~~~~~~~~~~~~~~~~~~~~ @@ -57,16 +61,30 @@ Helm `vFW_Helm Model`_ Helm templates used in `vFW EDGEX K8S`_ CDS model `vFW CBA Model`_ CDS CBA model used in `vFW CDS Dublin`_ demo =============== ================= =========== -All changes to related ONAP components and Use Case can be found from this `Jira Epic`_ ticket. +.. note:: Since the Guilin release `vFW_CNF_CDS Model`_ contains sources that allow to model and instantiate CNF with VNF/Heat orchestration approach (Frankfurt) and with native Helm orchestration approach (Guilin and beyond). VNF/Heat orchestration approach is deprecated and will not be enhanced in the future. Please follow README.txt description and further documentation here to generate and select appropriate onboarding package which will leverage appropriate SO orchestration path. + +Since Honolulu release vFW CNF use case supports three different scenarios where different capabilities of CNF Orchestration in ONAP can be experimented: + +.. figure:: files/vFW_CNF_CDS/scenarios.png + :scale: 60 % + :align: center + + vFW CNF Scenarios + +- Scenario 1: simple deployment of vFW CNF instance +- Scenario 2: deployment of vFW CNF instance with enrichment of the Helm deployment with profiling mechanism +- Scenario 3: deployment of vFW CNF instance with Day2 configuration applied and CNF status checked as a part of a config-deploy operation -Modeling Onboarding Package/Helm -................................ +The 3rd scenario presents the most comprehensive way of managing the CNF in ONAP, including Day 0/1/2 operations. It shows also how to combine in the Day2 operation information for the AAI and SDNC MDSAL. All scenarios can be supported by execution of the dedicated Healthcheck workflow `3-5 Verification of the CNF Status`_. + +Modeling of Onboarding Package/Helm +................................... The starting point for this demo was Helm package containing one Kubernetes application, see `vFW_Helm Model`_. In this demo we decided to follow SDC/SO vf-module concept the same way as original vFW demo was split into multiple vf-modules instead of one (`vFW_NextGen`_). The same way we splitted Helm version of vFW into multiple Helm packages each matching one dedicated vf-module. -Produced onboarding package has following MANIFEST file (package/MANIFEST.json) having all Helm packages modeled as dummy Heat resources matching to vf-module concept (that is originated from Heat), so basically each Helm application is visible to ONAP as own vf-module. Actual Helm package is delivered as CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT package through SDC and SO. Dummy heat templates are matched to helm packages by the same prefix of the file name. +The Jakarta version of the `vFW_CNF_CDS Model`_ contains files required to create **VSP onboarding packages in Helm Native format** where each Helm package is standalone and is natively understood in consequence by SO. The **Dummy Heat** (available in Frankfurt release already) one that considers association of each Helm package with dummy heat templates since Jakarta is not a prt of the vFW CNF demo. If you are interested to see how to onboard and orchestrate the CNF using the **Dummy Heat** approach, please open the Istanbul version of the documentation. The VSP Helm packages are matched to the vf-module concept, so basically each Helm application after instantiation is visible to ONAP as a separate vf-module. The **Native Helm** format for onboarding has **crucial** role in the further orchestration approach applied for Helm package instantiation as it leverages the **CNF Adapter** and it populates k8s resource information to AAI what plays significant role in the Day operation for CNFs, including closed-loop automation with Prometheus. Read more in `3-1 CNF Orchestration Paths in ONAP`_ -CDS model (CBA package) is delivered as SDC supported own type CONTROLLER_BLUEPRINT_ARCHIVE. +Produced **Native Helm** VSP onboarding package `Creating Onboarding Package`_ format has following MANIFEST file (package_native/MANIFEST.json). The Helm package is delivered as HELM package through SDC and SO. The *isBase* flag of HELM artifact is ignored by SDC but in the manifest one HELM or HEAT artifacts must be defined as isBase = true. If both HEAT and HELM are present in the same manifest file the base one must be always one of HELM artifacts. Moreover, the name of HELM type artifact **MUST** match the specified pattern: *helm_<some_name>* and the HEAT type artifacts, if present in the same manifest, cannot contain keyword *helm*. These limitations are a consequence of current limitations of the SDC onboarding and VSP validation engine and will be adresssed in the future releases. :: @@ -75,186 +93,92 @@ CDS model (CBA package) is delivered as SDC supported own type CONTROLLER_BLUEPR "description": "", "data": [ { - "file": "vFW_CDS_CNF.zip", + "file": "CBA.zip", "type": "CONTROLLER_BLUEPRINT_ARCHIVE" }, { - "file": "base_template.yaml", - "type": "HEAT", - "isBase": "true", - "data": [ - { - "file": "base_template.env", - "type": "HEAT_ENV" - } - ] - }, - { - "file": "base_template_cloudtech_k8s_charts.tgz", - "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT" - }, - { - "file": "vfw.yaml", - "type": "HEAT", - "isBase": "false", - "data": [ - { - "file": "vfw.env", - "type": "HEAT_ENV" - } - ] - }, - { - "file": "vfw_cloudtech_k8s_charts.tgz", - "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT" - }, - { - "file": "vpkg.yaml", - "type": "HEAT", - "isBase": "false", - "data": [ - { - "file": "vpkg.env", - "type": "HEAT_ENV" - } - ] + "file": "helm_base_template.tgz", + "type": "HELM", + "isBase": "true" }, { - "file": "vpkg_cloudtech_k8s_charts.tgz", - "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT" + "file": "helm_vfw.tgz", + "type": "HELM", + "isBase": "false" }, { - "file": "vsn.yaml", - "type": "HEAT", - "isBase": "false", - "data": [ - { - "file": "vsn.env", - "type": "HEAT_ENV" - } - ] + "file": "helm_vpkg.tgz", + "type": "HELM", + "isBase": "false" }, { - "file": "vsn_cloudtech_k8s_charts.tgz", - "type": "CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT" + "file": "helm_vsn.tgz", + "type": "HELM", + "isBase": "false" } ] } -Multicloud/k8s -.............. - -K8s plugin was changed to support new way to identify k8s application and related multicloud/k8s profile. - -Changes done: - -- SDC distribution broker - - SDC distribution broker is responsible for transformation of the CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT into *Definition* object holding the helm package. The change for Frankfurt release considers that singular onboarding package can have many CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT, each one for dedicated vf-module associated with dummy heat template. The mapping between vf-module and CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT is done on file prefixes. In example, *vfw.yaml* Heat template will result with creation of *vfw* vf-module and its Definition will be created from CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACT file of name vfw_cloudtech_k8s_charts.tgz. More examples can be found in `Modeling Onboarding Package/Helm`_ section. - -- K8S plugin APIs changed to use VF Module Model Identifiers - - Previously K8S plugin's used user given values in to identify object created/modified. Names were basing on VF-Module's "model-name"/"model-version" like "VfwLetsHopeLastOne..vfw..module-3" and "1". SO request has user_directives from where values was taken. - - **VF Module Model Invariant ID** and **VF Module Model Version ID** is now used to identify artifact in SO request to Multicloud/k8s plugin. This does not require user to give extra parameters for the SO request as vf-module related parameters are there already by default. `MULTICLOUD-941`_ - Note that API endpoints are not changed but only the semantics. - - *Examples:* +.. note:: CDS model (CBA package) is delivered as SDC supported own type CONTROLLER_BLUEPRINT_ARCHIVE but the current limitation of VSP onbarding forces to use the artifact name *CBA.zip* to automaticaly recognize CBA as a CONTROLLER_BLUEPRINT_ARCHIVE. - Definition - - :: - - /api/multicloud-k8s/v1/v1/rb/definition/{VF Module Model Invariant ID}/{VF Module Model Version ID}/content - - - Profile creation API - - :: - - curl -i -d @create_rbprofile.json -X POST http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/rb/definition/{VF Module Model Invariant ID}/{VF Module Model Version ID}/profile - { "rb-name": “{VF Module Model Invariant ID}", - "rb-version": "{VF Module Model Version ID}", - "profile-name": "p1", - "release-name": "r1", - "namespace": "testns1", - "kubernetes-version": "1.13.5" - } - - Upload Profile content API - - :: - - curl -i --data-binary @profile.tar.gz -X POST http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/rb/definition/{VF Module Model Invariant ID}/{VF Module Model Version ID}/profile/p1/content - -- Instantiation broker - - The broker implements `infra_workload`_ API used to handle vf-module instantiation request comming from the SO. User directives were changed by SDNC directives what impacts also the way how a'la carte instantiation method works from the VID. There is no need to specify the user directives delivered from the separate file. Instead SDNC directives are delivered through SDNC preloading (a'la carte instantiation) or through the resource assignment performed by the CDS (Macro flow instantiation). - - - For helm package instantiation following parameters have to be delivered in the SDNC directives: - - - ======================== ============================================== - - Variable Description - - ------------------------ ---------------------------------------------- - - k8s-rb-profile-name Name of the override profile - - k8s-rb-profile-namespace Name of the namespace for created helm package - - ======================== ============================================== - -- Default profile support was added to the plugin - - K8splugin now creates dummy "default" profile on each resource bundle registration. Such profile doesn't contain any content inside and allows instantiation of CNF without the need to define additional profile, however this is still possible. In this use-case, CBA has been defined in a way, that it can template some simple profile that can be later put by CDS during resource-assignment instantiation phase and later picked up for instantiation. This happens when using second prepared instantiation call for instantiation: **Postman -> LCM -> 6. [SO] Self-Serve Service Assign & Activate - Second** +CDS Model (CBA) +............... -- Instantiation time override support was added to the plugin +CDS plays a crucial role in the process of CNF instantiation and is responsible for delivery of instantiation parameters, CNF customization, configuration of CBF after the deployment and may be used in the process of CNF status verification. - K8splugin allows now specifying override parameters (similar to --set behavior of helm client) to instantiated resource bundles. This allows for providing dynamic parameters to instantiated resources without the need to create new profiles for this purpose. +Creating CDS model was the core of the use case work and also the most difficult and time consuming part. Current template used by use-case should be easily reusable for anyone. Once CDS GUI will be fully working, we think that CBA development should be much easier. For CBA structure reference, please visit it's documentation page `CDS Documentation`_. +At first the target was to keep CDS model as close as possible to `vFW_CNF_CDS Model`_ use case model and only add smallest possible changes to enable also k8s usage. That is still the target but in practice model deviated from the original one already and time pressure pushed us to not care about sync. Basically the end result could be possible much streamlined if wanted to be smallest possible to working only for K8S based network functions. -CDS Model (CBA) -............... +Base on this example there are demonstrated following features of CDS and CBA model -Creating CDS model was the core of the use case work and also the most difficult and time consuming part. There are many reasons for this e.g. +- resource assignment string, integer and json types +- sourcing of resolved value on vf-module level from vnf level assignment +- extracting data from AAI and MD-SAL during the resource assignment +- custom resource assignment with Kotlin script +- templating of the vtl files +- building of imperative workflows +- utilization of on_succes and on_failure event in imperative workflow +- handling of the failure in the workflow +- implementation of custom workflow logic with Kotlin script +- example of config-assign and config-deploy operation decomposed into many steps +- complex parametrization of config deploy operation +- combination and aggregation of AAI and MD-SAL data in config-assign and config-deploy operations -- CDS documentation (even being new component) is inadequate or non-existent for service modeler user. One would need to be CDS developer to be able to do something with it. -- CDS documentation what exists is non-versioned (in ONAP wiki when should be in git) so it's mostly impossible to know what features are for what release. -- Our little experience of CDS (not CDS developers) +The prepared CBA model demonstrates also how to utilize CNF specific features of CBA, suited for the deployment of CNF with k8splugin in ONAP: -Although initial development of template wasn't easy, current template used by use-case should be easily reusable for anyone. Once CDS GUI will be fully working, we think that CBA development should be much easier. For CBA structure reference, please visit it's documentation page `CDS Modeling Concepts`_. +- building and upload of k8s profile template into k8splugin +- building and upload of k8s configuration template into k8splugin +- parametrization and creation of configuration instance from configuration template +- validation of CNF status with Kotlin script +- execution of the CNF healtcheck -At first the target was to keep CDS model as close as possible to `vFW_CNF_CDS Model`_ use case model and only add smallest possible changes to enable also k8s usage. That is still the target but in practice model deviated from the original one already and time pressure pushed us to not care about sync. Basically the end result could be possible much streamlined if wanted to be smallest possible to working only for K8S based network functions. - -As K8S application was split into multiple Helm packages to match vf-modules, CBA modeling follows the same and for each vf-module there's own template in CBA package. +As K8S application is split into multiple Helm packages to match vf-modules, CBA modeling follows the same and for each vf-module there's own template in CBA package. The **Native Helm** approach, requires the Helm artifact names to star with *helm_* prefix, in the same way like names of artifacts in the MANIFEST file of VSP differs. The **Native Helm** artifacts' list is following: :: "artifacts" : { - "base_template-template" : { + "helm_base_template-template" : { "type" : "artifact-template-velocity", "file" : "Templates/base_template-template.vtl" }, - "base_template-mapping" : { + "helm_base_template-mapping" : { "type" : "artifact-mapping-resource", "file" : "Templates/base_template-mapping.json" }, - "vpkg-template" : { + "helm_vpkg-template" : { "type" : "artifact-template-velocity", "file" : "Templates/vpkg-template.vtl" }, - "vpkg-mapping" : { + "helm_vpkg-mapping" : { "type" : "artifact-mapping-resource", "file" : "Templates/vpkg-mapping.json" }, - "vfw-template" : { + "helm_vfw-template" : { "type" : "artifact-template-velocity", "file" : "Templates/vfw-template.vtl" }, - "vfw-mapping" : { + "helm_vfw-mapping" : { "type" : "artifact-mapping-resource", "file" : "Templates/vfw-mapping.json" }, @@ -266,37 +190,36 @@ As K8S application was split into multiple Helm packages to match vf-modules, CB "type" : "artifact-mapping-resource", "file" : "Templates/vnf-mapping.json" }, - "vsn-template" : { + "helm_vsn-template" : { "type" : "artifact-template-velocity", "file" : "Templates/vsn-template.vtl" }, - "vsn-mapping" : { + "helm_vsn-mapping" : { "type" : "artifact-mapping-resource", "file" : "Templates/vsn-mapping.json" } } -Only **resource-assignment** workflow of the CBA model is utilized in this demo. If final CBA model contains also **config-deploy** workflow it's there just to keep parity with original vFW CBA (for VMs). Same applies for the related template *Templates/nf-params-template.vtl* and it's mapping file. +SO requires for instantiation name of the profile in the parameter: *k8s-rb-profile-name* and name of the release of thr application: *k8s-rb-instance-release-name*. The latter one, when not specified, will be replaced with combination of profile name and vf-module-id for each Helm instance/vf-module instantiated. Both values can be found in vtl templates dedicated for vf-modules. + +CBA offers possibility of the automatic generation and upload to multicloud/k8s plugin the RB profile content. RB profile is required if you want to deploy your CNF into k8s namesapce other than *default*. Also, if you want to ensure particular templating of your Helm charts, specific to particular version of the cluster into which Helm packages will deployed on, profile is used to specify the version of your cluster. -Another advance of the presented use case over solution presented in the Dublin release is possibility of the automatic generation and upload to multicloud/k8s plugin the RB profile content. -RB profile can be used to enrich or to modify the content of the original helm package. Profile can be also used to add additional k8s helm templates for helm installation or can be used to -modify existing k8s helm templates for each create CNF instance. It opens another level of CNF customization, much more than customization og helm package with override values. +RB profile can be used to enrich or to modify the content of the original helm package. Profile can be also used to add additional k8s helm templates for helm installation or can be used to modify existing k8s helm templates for each create CNF instance. It opens another level of CNF customization, much more than customization of the Helm package with override values. K8splugin offers also *default* profile without content, for default namespace and default cluster version. :: --- version: v1 type: - values: “override_values.yaml” + values: "override_values.yaml" configresource: - filepath: resources/deployment.yaml chartpath: templates/deployment.yaml -Above we have exemplary manifest file of the RB profile. Since Frankfurt *override_values.yaml* file does not need to be used as instantiation values are passed to the plugin over Instance API of k8s plugin. In the example profile contains additional k8s helm template which will be added on demand -to the helm package during its installation. In our case, depending on the SO instantiation request input parameters, vPGN helm package can be enriched with additional ssh service. Such service will be dynamically added to the profile by CDS and later on CDS will upload whole custom RB profile to multicloud/k8s plugin. +Above we have exemplary manifest file of the RB profile. Since Frankfurt *override_values.yaml* file does not need to be used as instantiation values are passed to the plugin over Instance API of k8s plugin. In the example, profile contains additional k8s Helm template which will be added on demand to the helm package during its installation. In our case, depending on the SO instantiation request input parameters, vPGN helm package can be enriched with additional ssh service. Such service will be dynamically added to the profile by CDS and later on CDS will upload whole custom RB profile to multicloud/k8s plugin. -In order to support generation and upload of profile, our vFW CBA model has enhanced **resource-assignment** workflow which contains additional steps, **profile-modification** and **profile-upload**. For the last step custom Kotlin script included in the CBA is used to upload K8S profile into multicloud/k8s plugin. +In order to support generation and upload of profile, our vFW CBA model has enhanced **resource-assignment** workflow which contains additional step: **profile-upload**. It leverages dedicated functionality introduced in Guilin release that can be used to upload predefined profile or to generate and upload content of the profile with Velocity templating mechanism. :: @@ -311,24 +234,12 @@ In order to support generation and upload of profile, our vFW CBA model has enha } ], "on_success": [ - "profile-modification" - ] - }, - "profile-modification": { - "description": "Profile Modification Resources", - "target": "profile-modification", - "activities": [ - { - "call_operation": "ResourceResolutionComponent.process" - } - ], - "on_success": [ "profile-upload" ] }, "profile-upload": { - "description": "Upload K8s Profile", - "target": "profile-upload", + "description": "Generate and upload K8s Profile", + "target": "k8s-profile-upload", "activities": [ { "call_operation": "ComponentScriptExecutor.process" @@ -337,7 +248,26 @@ In order to support generation and upload of profile, our vFW CBA model has enha } }, -Profile generation step uses embedded into CDS functionality of templates processing and on its basis ssh port number (specified in the SO request as vpg-management-port) is included in the ssh service helm template. +.. note:: In the Frankfurt release profile upload was implemented as a custom Kotlin script included into the CBA. It was responsible for upload of K8S profile into multicloud/k8s plugin. It is still a good example of the integration of Kotlin scripting into the CBA. For those interested in this functionaliy we recommend to look into the `Frankfurt CBA Definition`_ and `Frankfurt CBA Script`_. Since Honolulu we introduce more advanced use of the Kotlin script for verification of the CNF status or custom resolution of complex parameters over Kotlin script - both can be found in the further part of the documentation. + +In our example for vPKG helm package we may select *vfw-cnf-cds-vpkg-profile* profile that is included into CBA as a folder. Profile generation step uses Velocity templates processing embedded CDS functionality on its basis ssh port number (specified in the SO request as *vpg-management-port*). + +:: + + { + "name": "vpg-management-port", + "property": { + "description": "The number of node port for ssh service of vpg", + "type": "integer", + "default": "0" + }, + "input-param": false, + "dictionary-name": "vpg-management-port", + "dictionary-source": "default", + "dependencies": [] + } + +*vpg-management-port* can be included directly into the helm template and such template will be included into vPKG helm package in time of its instantiation. :: @@ -360,1214 +290,276 @@ Profile generation step uses embedded into CDS functionality of templates proces release: {{ .Release.Name }} chart: {{ .Chart.Name }} -To upload of the profile is conducted with the CDS capability to execute Kotlin scripts. It allows to define any required controller logic. In our case we use to implement decision point and mechanisms of profile generation and upload. -During the generation CDS extracts the RB profile template included in the CBA, includes there generated ssh service helm template, modifies the manifest of RB template by adding there ssh service and after its archivisation sends the profile to -k8s plugin. +.. warning:: The port value is of Integer type and CDS resolves it as an integer. If the resolved values are returned to SO during the resource resolution phase they are being passed to k8splugin back only as a strings. In consequence, Integer values are passed to the Instantiation API as a strings and then they have go be converted in the helm template to the integer. In order to avoid such conversion it is better to customize override values with Integers in the profile and to skip return of this parameters in the resource resolution phase (they should not be included in the .vtl files). + +The mechanism of profile generation and upload requires specific node teamplate in the CBA definition. In our case, it comes with the declaration of two profiles: one static *vfw-cnf-cds-base-profile* in a form of an archive and the second complex *vfw-cnf-cds-vpkg-profile* in a form of a folder for processing and profile generation. Below is the example of the definition of node type for execution of the profile upload operation. :: - "profile-modification": { - "type": "component-resource-resolution", + "k8s-profile-upload": { + "type": "component-k8s-profile-upload", "interfaces": { - "ResourceResolutionComponent": { + "K8sProfileUploadComponent": { "operations": { "process": { "inputs": { - "artifact-prefix-names": [ - "ssh-service" - ] + "artifact-prefix-names": { + "get_input": "template-prefix" + }, + "resource-assignment-map": { + "get_attribute": [ + "resource-assignment", + "assignment-map" + ] + } } } } } }, "artifacts": { - "ssh-service-template": { - "type": "artifact-template-velocity", - "file": "Templates/k8s-profiles/ssh-service-template.vtl" + "vfw-cnf-cds-base-profile": { + "type": "artifact-k8sprofile-content", + "file": "Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz" }, - "ssh-service-mapping": { + "vfw-cnf-cds-vpkg-profile": { + "type": "artifact-k8sprofile-content", + "file": "Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile" + }, + "vfw-cnf-cds-vpkg-profile-mapping": { "type": "artifact-mapping-resource", - "file": "Templates/k8s-profiles/ssh-service-mapping.json" - } - } - }, - "profile-upload": { - "type": "component-script-executor", - "interfaces": { - "ComponentScriptExecutor": { - "operations": { - "process": { - "inputs": { - "script-type": "kotlin", - "script-class-reference": "org.onap.ccsdk.cds.blueprintsprocessor.services.execution.scripts.K8sProfileUpload", - "dynamic-properties": "*profile-upload-properties" - } - } - } + "file": "Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json" } } } -Kotlin script expects that K8S profile template named like "k8s-rb-profile-name".tar.gz is present in CBA "Templates/k8s-profiles" directory where **k8s-rb-profile-name** is one of the CDS resolved parameters (user provides as input parameter) and in our case it has a value **vfw-cnf-cds-base-profile**. +Artifact file determines a place of the static profile or the content of the complex profile. In the latter case we need a pair of profile folder and mapping file with a declaration of the parameters that CDS needs to resolve first, before the Velocity templating is applied to the .vtl files present in the profile content. After Velocity templating the .vtl extensions will be dropped from the file names. The embedded mechanism will include in the profile only files present in the profile MANIFEST file that needs to contain the list of final names of the files to be included into the profile. The figure below shows the idea of profile templating. -Finally, `Data Dictionary`_ is also included into demo git directory, re-modeling and making changes into model utilizing CDS model time / runtime is easier as used DD is also known. +.. figure:: files/vFW_CNF_CDS/profile-templating.png + :align: center -UAT -+++ + K8s Profile Templating +SO requires for instantiation name of the profile in the parameter: *k8s-rb-profile-name*. The *component-k8s-profile-upload* that stands behind the profile uploading mechanism has input parameters that can be passed directly (checked in the first order) or can be taken from the *resource-assignment-map* parameter which can be a result of associated *component-resource-resolution* result, like in our case their values are resolved on vf-module level resource assignment. The *component-k8s-profile-upload* inputs are following: -UAT is a nice concept where CDS CBA can be tested isolated after all external calls it makes are recorded. UAT framework in CDS has spy mode that enables such recording of requets. Recording is initiated with structured yaml file having all CDS requests and spy mode executes all those requests in given yaml file and procuding another yaml file where external requetsts and payloads are recorded. +- k8s-rb-definition-name [string] - (mandatory) the name under which RB definition was created - **VF Module Model Invariant ID** in ONAP +- k8s-rb-definition-version [string] - (mandatory) the version of created RB definition name - **VF Module Model Customization ID** in ONAP +- k8s-rb-profile-name [string] - (mandatory) the name of the profile under which it will be created in k8s plugin. Other parameters are required only when profile must be uploaded because it does not exist yet +- k8s-rb-profile-source [string] - the source of profile content - name of the artifact of the profile. If missing *k8s-rb-profile-name* is treated as a source +- k8s-rb-profile-namespace [string] - (mandatory) the k8s namespace name associated with profile being created +- k8s-rb-profile-kubernetes-version [string] - the version of the cluster on which application will be deployed - it may impact the helm templating process like selection of the api versions for resources so it should match the version of k8s cluster in which resources are bing deployed. +- k8s-rb-profile-labels [json] - the extra labels (label-name: label-value) to add for each k8s resource created for CNF in the k8s cluster (since Jakarta release). +- k8s-rb-profile-extra-types [list<json>] - the list of extra k8s types that should be returned by StatusAPI. It may be usefull when k8s resources associated with CNF instance are created outside of the helm package (i.e. by k8s operator) but should be treated like resources of CNF. To make it hapens such resources should have the instance label *k8splugin.io/rb-instance-id* what may be assured by such tools like *kyverno*. Each extra type json object needs *Group*, *Version* and *Kind* attributes. (since Jakarta release). +- resource-assignment-map [json] - result of the associated resource assignment step - it may deliver values of inputs if they are not specified directly +- artifact-prefix-names [list<string>] - (mandatory) the list of artifact prefixes like for resource-assigment step in the resource-assigment workflow or its subset -During this use case we had several problems with UAT testing and finally we where not able to get it fully working. UAT framework is not taking consideration that of subsequent CDS calls does have affects to external componenets like SDNC MDSAL (particularly the first resource-assignment call comING FROM sdnc stored resolved values to MDSAL and those are needed by subsequent calls by CBA model). +In the SO request user can pass parameter of name *k8s-rb-profile-name* which in our case may have value: *vfw-cnf-cds-base-profile*, *vfw-cnf-cds-vpkg-profile* or *default*. The *default* profile does not contain any content inside and allows instantiation of CNF without the need to define and upload any additional profiles. *vfw-cnf-cds-vpkg-profile* has been prepared to test instantiation of the second modified vFW CNF instance. -It was possible to record CDS calls with UAT spy after successfull instantition when SDNC was alredy populated with resolved values are re-run of CDS model was able to fetch needed values. +K8splugin allows to specify override parameters (similar to --set behavior of helm client) to instantiated resource bundles. This allows for providing dynamic parameters to instantiated resources without the need to create new profiles for this purpose. This mechanism should be used with *default* profile but may be used also with any custom profile. -During testing of the use case **uat.yml** file was recorded according to `CDS UAT Testing`_ instructions. Generated uat.yml could be stored (if usable) within CBA package into **Tests** folder. +The overall flow of helm overrides parameters processing is visible on following figure. When *rb definition* (helm package) is being instantiated for specified *rb profile* K8splugin combines override values from the helm package, *rb profile* and from the instantiation request - in the respective order. It means that the value from the instantiation request (SO request input or CDS resource assignment result) has a precedence over the value from the *rb profile* and value from the *rb profile* has a precedence over the helm package default override value. Similarly, profile can contain resource files that may extend or ammend the existing files for the original helm package content. -Recorded uat.yml is an example run with example values (the values we used when demo was run) and can be used later to test CBA model in isolation (unit test style). This could be very useful when changes are made to CBA model and those changes are needed to be tested fast. With uat.yml file only CDS is needed as all external interfaces are mocked. However, note that mocking is possible for REST interfaces only (e.g. Netconf is not supported). +.. figure:: files/vFW_CNF_CDS/helm-overrides.png + :align: center + + The overall flow of helm data processing -Another benefit of uat.yml is that it documents the runtime functionality of the CBA and that's the main benefit on this use case as the UAT test (verify) part was not really successful. +Both profile content (4) like the instantiation request values (5) can be generated during the resource assignment process according to its definition for CBA associated with helm package. CBA may generate i.e. names, IP addresses, ports and can use this information to produce the *rb-profile* (3) content. Finally, all three sources of override values, temnplates and additional resources files are merged together (6) by K8splugin in the order exaplained before. -To verify CBA with uat.yaml and CDS runtime do following: +.. figure:: files/vFW_CNF_CDS/helm-overrides-steps.png + :align: center -- Enable UAT testing for CDS runtime + The steps of processing of helm data with help of CDS - :: +Both profile content (4) like the instantiation request values (5) can be generated during the resource assignment process according to its definition for CBA associated with helm package. CBA may generate i.e. names, IP addresses, ports and can use this information to produce the *rb-profile* (3) content. Finally, all three sources of override values, temnplates and additional resources files are merged together (6) by K8splugin in the order exaplained before. - kubectl -n onap edit deployment onap-cds-blueprints-processor +Besides the deployment of Helm application the CBA of vFW demonstrates also how to use deicated features for config-assign (7) and config-deploy (8) operations. In the use case, *config-assign* and *config-deploy* operations deal mainly with creation and instantiation of configuration template for k8s plugin. The configuration template has a form of Helm package. When k8s plugin instantiates configuration, it creates or may replace existing resources deployed on k8s cluster. In our case the configuration template is used to provide alternative way of upload of the additional ssh-service but it coud be used to modify configmap of vfw or vpkg vf-modules. - # add env variable for cds-blueprints-processor container: - name: spring_profiles_active - value: uat +In order to provide configuration instantiation capability standard *config-assign* and *config-deploy* workflows have been changed into imperative workflows with first step responsible for collection of information for configuration templating and configuration instantiation. The source of data for this operations is AAI, MDSAL with data for vnf and vf-modules as *config-assign* and *config-deploy* does not receive dedicated input parameters from SO. In consequence both operations need to source from *resource-assignment* phase and data placed in the AAI and MDSAL. -- Spy CBA functionality with UAT initial seed file +vFW CNF *config-assign* workflow is following: :: - curl -X POST -u ccsdkapps:ccsdkapps -F cba=@my_cba.zip -F uat=@input_uat.yaml http://<kube-node>:30499/api/v1/uat/spy + "config-assign": { + "steps": { + "config-setup": { + "description": "Gather necessary input for config template upload", + "target": "config-setup-process", + "activities": [ + { + "call_operation": "ResourceResolutionComponent.process" + } + ], + "on_success": [ + "config-template" + ] + }, + "config-template": { + "description": "Generate and upload K8s config template", + "target": "k8s-config-template", + "activities": [ + { + "call_operation": "K8sConfigTemplateComponent.process" + } + ] + } + }, -where my_cba.zip is the cba model of this use case and input_uat.yml is following in this use case: +vFW CNF *config-deploy* workflow is following: :: - %YAML 1.1 - --- - processes: - - name: resource-assignment for vnf - request: - commonHeader: &commonHeader - originatorId: SDNC_DG - requestId: "98397f54-fa57-485f-a04e-1e220b7b1779" - subRequestId: "6bfca5dc-993d-48f1-ad27-a7a9ea91836b" - actionIdentifiers: &actionIdentifiers - blueprintName: vFW_CNF_CDS - blueprintVersion: "1.0.45" - actionName: resource-assignment - mode: sync - payload: - resource-assignment-request: - template-prefix: - - "vnf" - resource-assignment-properties: - service-instance-id: &service-id "8ead0480-cf44-428e-a4c2-0e6ed10f7a72" - vnf-model-customization-uuid: &vnf-model-cust-uuid "86dc8af4-aa17-4fc7-9b20-f12160d99718" - vnf-id: &vnf-id "93b3350d-ed6f-413b-9cc5-a158c1676eb0" - aic-cloud-region: &cloud-region "k8sregionfour" - - name: resource-assignment for base_template - request: - commonHeader: *commonHeader - actionIdentifiers: *actionIdentifiers - payload: - resource-assignment-request: - template-prefix: - - "base_template" - resource-assignment-properties: - nfc-naming-code: "base_template" - k8s-rb-profile-name: &k8s-profile-name "default" - service-instance-id: *service-id - vnf-id: *vnf-id - vf-module-model-customization-uuid: "b27fad11-44da-4840-9256-7ed8a32fbe3e" - vnf-model-customization-uuid: *vnf-model-cust-uuid - vf-module-id: "274f4bc9-7679-4767-b34d-1df51cdf2496" - aic-cloud-region: *cloud-region - - name: resource-assignment for vpkg - request: - commonHeader: *commonHeader - actionIdentifiers: *actionIdentifiers - payload: - resource-assignment-request: - template-prefix: - - "vpkg" - resource-assignment-properties: - nfc-naming-code: "vpkg" - k8s-rb-profile-name: *k8s-profile-name - service-instance-id: *service-id - vnf-id: *vnf-id - vf-module-model-customization-uuid: "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb" - vnf-model-customization-uuid: *vnf-model-cust-uuid - vf-module-id: "011b5f61-6524-4789-bd9a-44cfbf321463" - aic-cloud-region: *cloud-region - - name: resource-assignment for vsn - request: - commonHeader: *commonHeader - actionIdentifiers: *actionIdentifiers - payload: - resource-assignment-request: - template-prefix: - - "vsn" - resource-assignment-properties: - nfc-naming-code: "vsn" - k8s-rb-profile-name: *k8s-profile-name - service-instance-id: *service-id - vnf-id: *vnf-id - vf-module-model-customization-uuid: "4cac0584-c0d6-42a7-bdb3-29162792e07f" - vnf-model-customization-uuid: *vnf-model-cust-uuid - vf-module-id: "0cbf558f-5a96-4555-b476-7df8163521aa" - aic-cloud-region: *cloud-region - - name: resource-assignment for vfw - request: - commonHeader: *commonHeader - actionIdentifiers: *actionIdentifiers - payload: - resource-assignment-request: - template-prefix: - - "vfw" - resource-assignment-properties: - nfc-naming-code: "vfw" - k8s-rb-profile-name: *k8s-profile-name - service-instance-id: *service-id - vnf-id: *vnf-id - vf-module-model-customization-uuid: "1e123e43-ba40-4c93-90d7-b9f27407ec03" - vnf-model-customization-uuid: *vnf-model-cust-uuid - vf-module-id: "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f " - aic-cloud-region: *cloud-region - - -.. note:: This call will run all the calls (given in input_uat.yml) towards CDS and records the functionality, so there needs to be working environment (SDNC, AAI, Naming, Netbox, etc.) to record valid final uat.yml. - As an output of this call final uat.yml content is received. Final uat.yml in this use case looks like this: + "config-deploy": { + "steps": { + "config-setup": { + "description": "Gather necessary input for config init and status verification", + "target": "config-setup-process", + "activities": [ + { + "call_operation": "ResourceResolutionComponent.process" + } + ], + "on_success": [ + "config-apply" + ] + }, + "config-apply": { + "description": "Activate K8s config template", + "target": "k8s-config-apply", + "activities": [ + { + "call_operation": "K8sConfigTemplateComponent.process" + } + ], + "on_success": [ + "status-verification-script" + ] + }, + + +In our example configuration template for vFW CNF is a helm package that contains the same resource that we can find in the vPKG *vfw-cnf-cds-vpkg-profile* profile - extra ssh service. This helm package contains Helm encapsulation for ssh-service and the values.yaml file with declaration of all the inputs that may parametrize the ssh-service. The configuration templating step leverages the *component-k8s-config-template* component that prepares the configuration template and uploads it to k8splugin. In consequence, it may be used later on for instatiation of the configuration. + +In this use case we have two options with *ssh-service-config* and *ssh-service-config-customizable* as a source of the same configuration template. In consequence, or we take a complete template or we have have the template folder with the content of the helm package and CDS may perform dedicated resource resolution for it with templating of all the files with .vtl extensions. The process is very similar to the one describe for profile upload functionality. :: - processes: - - name: resource-assignment for vnf - request: - commonHeader: - originatorId: SDNC_DG - requestId: 98397f54-fa57-485f-a04e-1e220b7b1779 - subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b - actionIdentifiers: - blueprintName: vFW_CNF_CDS - blueprintVersion: 1.0.45 - actionName: resource-assignment - mode: sync - payload: - resource-assignment-request: - template-prefix: - - vnf - resource-assignment-properties: - service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72 - vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718 - vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0 - aic-cloud-region: k8sregionfour - expectedResponse: - commonHeader: - originatorId: SDNC_DG - requestId: 98397f54-fa57-485f-a04e-1e220b7b1779 - subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b - flags: null - actionIdentifiers: - blueprintName: vFW_CNF_CDS - blueprintVersion: 1.0.45 - actionName: resource-assignment - mode: sync - status: - code: 200 - eventType: EVENT_COMPONENT_EXECUTED - errorMessage: null - message: success - payload: - resource-assignment-response: - meshed-template: - vnf: | - { - "capability-data": [ - { - "capability-name": "generate-name", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "vnf_name", - "resource-value": "${vnf_name}" - } - ], - "payload": [ - { - "param-name": "resource-name", - "param-value": "vnf_name" - }, - { - "param-name": "resource-value", - "param-value": "${vnf_name}" - }, - { - "param-name": "external-key", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0_vnf_name" - }, - { - "param-name": "policy-instance-name", - "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP" - }, - { - "param-name": "naming-type", - "param-value": "VNF" - }, - { - "param-name": "AIC_CLOUD_REGION", - "param-value": "k8sregionfour" - } - ] - } - ] - }, - { - "capability-name": "netbox-ip-assign", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "int_private1_gw_ip", - "resource-value": "${int_private1_gw_ip}" - } - ], - "payload": [ - { - "param-name": "service-instance-id", - "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72" - }, - { - "param-name": "prefix-id", - "param-value": "2" - }, - { - "param-name": "vnf-id", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0" - }, - { - "param-name": "external_key", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-int_private1_gw_ip" - } - ] - }, - { - "output-key-mapping": [ - { - "resource-name": "int_private2_gw_ip", - "resource-value": "${int_private2_gw_ip}" - } - ], - "payload": [ - { - "param-name": "service-instance-id", - "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72" - }, - { - "param-name": "prefix-id", - "param-value": "1" - }, - { - "param-name": "vnf-id", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0" - }, - { - "param-name": "external_key", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-int_private2_gw_ip" - } - ] - }, - { - "output-key-mapping": [ - { - "resource-name": "vfw_int_private2_ip_0", - "resource-value": "${vfw_int_private2_ip_0}" - } - ], - "payload": [ - { - "param-name": "service-instance-id", - "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72" - }, - { - "param-name": "prefix-id", - "param-value": "1" - }, - { - "param-name": "vnf-id", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0" - }, - { - "param-name": "external_key", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vfw_int_private2_ip_0" - } - ] - }, - { - "output-key-mapping": [ - { - "resource-name": "vfw_int_private1_ip_0", - "resource-value": "${vfw_int_private1_ip_0}" - } - ], - "payload": [ - { - "param-name": "service-instance-id", - "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72" - }, - { - "param-name": "prefix-id", - "param-value": "2" - }, - { - "param-name": "vnf-id", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0" - }, - { - "param-name": "external_key", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vfw_int_private1_ip_0" - } - ] - }, - { - "output-key-mapping": [ - { - "resource-name": "vsn_int_private2_ip_0", - "resource-value": "${vsn_int_private2_ip_0}" - } - ], - "payload": [ - { - "param-name": "service-instance-id", - "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72" - }, - { - "param-name": "prefix-id", - "param-value": "1" - }, - { - "param-name": "vnf-id", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0" - }, - { - "param-name": "external_key", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vsn_int_private2_ip_0" - } - ] - }, - { - "output-key-mapping": [ - { - "resource-name": "vpg_int_private1_ip_0", - "resource-value": "${vpg_int_private1_ip_0}" - } - ], - "payload": [ - { - "param-name": "service-instance-id", - "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72" - }, - { - "param-name": "prefix-id", - "param-value": "2" - }, - { - "param-name": "vnf-id", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0" - }, - { - "param-name": "external_key", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vpg_int_private1_ip_0" - } - ] - } - ] - }, - { - "capability-name": "unresolved-composite-data", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "int_private2_net_id", - "resource-value": "${vnf_name}-protected-network" - }, - { - "resource-name": "int_private1_net_id", - "resource-value": "${vnf_name}-unprotected-network" - }, - { - "resource-name": "onap_private_net_id", - "resource-value": "${vnf_name}-management-network" - }, - { - "resource-name": "net_attachment_definition", - "resource-value": "${vnf_name}-ovn-nat" - } - ] - } - ] - } - ], - "resource-accumulator-resolved-data": [ - { - "param-name": "vf-naming-policy", - "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP" - }, - { - "param-name": "dcae_collector_ip", - "param-value": "10.0.4.1" - }, - { - "param-name": "dcae_collector_port", - "param-value": "30235" - }, - { - "param-name": "int_private1_net_cidr", - "param-value": "192.168.10.0/24" - }, - { - "param-name": "int_private2_net_cidr", - "param-value": "192.168.20.0/24" - }, - { - "param-name": "onap_private_net_cidr", - "param-value": "10.0.101.0/24" - }, - { - "param-name": "demo_artifacts_version", - "param-value": "1.5.0" - }, - { - "param-name": "k8s-rb-profile-name", - "param-value": "vfw-cnf-cds-base-profile" - }, - { - "param-name": "k8s-rb-profile-namespace", - "param-value": "default" - } - ] - } - - name: resource-assignment for base_template - request: - commonHeader: - originatorId: SDNC_DG - requestId: 98397f54-fa57-485f-a04e-1e220b7b1779 - subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b - actionIdentifiers: - blueprintName: vFW_CNF_CDS - blueprintVersion: 1.0.45 - actionName: resource-assignment - mode: sync - payload: - resource-assignment-request: - template-prefix: - - base_template - resource-assignment-properties: - nfc-naming-code: base_template - k8s-rb-profile-name: default - service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72 - vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0 - vf-module-model-customization-uuid: b27fad11-44da-4840-9256-7ed8a32fbe3e - vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718 - vf-module-id: 274f4bc9-7679-4767-b34d-1df51cdf2496 - aic-cloud-region: k8sregionfour - expectedResponse: - commonHeader: - originatorId: SDNC_DG - requestId: 98397f54-fa57-485f-a04e-1e220b7b1779 - subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b - flags: null - actionIdentifiers: - blueprintName: vFW_CNF_CDS - blueprintVersion: 1.0.45 - actionName: resource-assignment - mode: sync - status: - code: 200 - eventType: EVENT_COMPONENT_EXECUTED - errorMessage: null - message: success - payload: - resource-assignment-response: - meshed-template: - base_template: | - { - "capability-data": [ - { - "capability-name": "netbox-ip-assign", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "onap_private_gw_ip", - "resource-value": "${onap_private_gw_ip}" - } - ], - "payload": [ - { - "param-name": "service-instance-id", - "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72" - }, - { - "param-name": "prefix-id", - "param-value": "3" - }, - { - "param-name": "vnf-id", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0" - }, - { - "param-name": "external_key", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-onap_private_gw_ip" - } - ] - } - ] - }, - { - "capability-name": "generate-name", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "vf_module_name", - "resource-value": "${vf-module-name}" - } - ], - "payload": [ - { - "param-name": "resource-name", - "param-value": "vf_module_name" - }, - { - "param-name": "resource-value", - "param-value": "${vf-module-name}" - }, - { - "param-name": "external-key", - "param-value": "274f4bc9-7679-4767-b34d-1df51cdf2496_vf-module-name" - }, - { - "param-name": "policy-instance-name", - "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP" - }, - { - "param-name": "naming-type", - "param-value": "VF-MODULE" - }, - { - "param-name": "VNF_NAME", - "param-value": "k8sregionfour-onap-nf-20200601t073308018z" - }, - { - "param-name": "VF_MODULE_TYPE", - "param-value": "vfmt" - }, - { - "param-name": "VF_MODULE_LABEL", - "param-value": "base_template" - } - ] - } - ] - }, - { - "capability-name": "aai-vf-module-put", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "aai-vf-module-put", - "resource-value": "" - } - ] - } - ] - } - ], - "resource-accumulator-resolved-data": [ - { - "param-name": "vf-module-model-invariant-uuid", - "param-value": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423" - }, - { - "param-name": "vf-module-model-version", - "param-value": "274f4bc9-7679-4767-b34d-1df51cdf2496" - }, - { - "param-name": "k8s-rb-profile-name", - "param-value": "default" - }, - { - "param-name": "k8s-rb-profile-namespace", - "param-value": "default" - }, - { - "param-name": "int_private1_subnet_id", - "param-value": "unprotected-network-subnet-1" - }, - { - "param-name": "int_private2_subnet_id", - "param-value": "protected-network-subnet-1" - }, - { - "param-name": "onap_private_subnet_id", - "param-value": "management-network-subnet-1" - } - ] - } - - name: resource-assignment for vpkg - request: - commonHeader: - originatorId: SDNC_DG - requestId: 98397f54-fa57-485f-a04e-1e220b7b1779 - subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b - actionIdentifiers: - blueprintName: vFW_CNF_CDS - blueprintVersion: 1.0.45 - actionName: resource-assignment - mode: sync - payload: - resource-assignment-request: - template-prefix: - - vpkg - resource-assignment-properties: - nfc-naming-code: vpkg - k8s-rb-profile-name: default - service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72 - vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0 - vf-module-model-customization-uuid: 4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb - vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718 - vf-module-id: 011b5f61-6524-4789-bd9a-44cfbf321463 - aic-cloud-region: k8sregionfour - expectedResponse: - commonHeader: - originatorId: SDNC_DG - requestId: 98397f54-fa57-485f-a04e-1e220b7b1779 - subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b - flags: null - actionIdentifiers: - blueprintName: vFW_CNF_CDS - blueprintVersion: 1.0.45 - actionName: resource-assignment - mode: sync - status: - code: 200 - eventType: EVENT_COMPONENT_EXECUTED - errorMessage: null - message: success - payload: - resource-assignment-response: - meshed-template: - vpkg: | - { - "capability-data": [ - { - "capability-name": "netbox-ip-assign", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "vpg_onap_private_ip_0", - "resource-value": "${vpg_onap_private_ip_0}" - } - ], - "payload": [ - { - "param-name": "service-instance-id", - "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72" - }, - { - "param-name": "prefix-id", - "param-value": "3" - }, - { - "param-name": "vnf-id", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0" - }, - { - "param-name": "external_key", - "param-value": "93b3350d-ed6f-413b-9cc5-a158c1676eb0-vpg_onap_private_ip_0" - } - ] - } - ] - }, - { - "capability-name": "generate-name", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "vf_module_name", - "resource-value": "${vf-module-name}" - } - ], - "payload": [ - { - "param-name": "VF_MODULE_TYPE", - "param-value": "vfmt" - }, - { - "param-name": "resource-name", - "param-value": "vf_module_name" - }, - { - "param-name": "resource-value", - "param-value": "${vf-module-name}" - }, - { - "param-name": "external-key", - "param-value": "011b5f61-6524-4789-bd9a-44cfbf321463_vf-module-name" - }, - { - "param-name": "policy-instance-name", - "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP" - }, - { - "param-name": "naming-type", - "param-value": "VF-MODULE" - }, - { - "param-name": "VNF_NAME", - "param-value": "k8sregionfour-onap-nf-20200601t073308018z" - }, - { - "param-name": "VF_MODULE_LABEL", - "param-value": "vpkg" - } - ] - } - ] - }, - { - "capability-name": "aai-vf-module-put", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "aai-vf-module-put", - "resource-value": "" - } - ] - } - ] - }, - { - "capability-name": "unresolved-composite-data", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "vpg_name_0", - "resource-value": "${vf_module_name}" - } - ] - } - ] - } - ], - "resource-accumulator-resolved-data": [ - { - "param-name": "vf-module-model-invariant-uuid", - "param-value": "4e2b9975-5214-48b8-861a-5701c09eedfa" - }, - { - "param-name": "vf-module-model-version", - "param-value": "011b5f61-6524-4789-bd9a-44cfbf321463" - }, - { - "param-name": "k8s-rb-profile-name", - "param-value": "default" - }, - { - "param-name": "k8s-rb-profile-namespace", - "param-value": "default" - } - ] - } - - name: resource-assignment for vsn - request: - commonHeader: - originatorId: SDNC_DG - requestId: 98397f54-fa57-485f-a04e-1e220b7b1779 - subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b - actionIdentifiers: - blueprintName: vFW_CNF_CDS - blueprintVersion: 1.0.45 - actionName: resource-assignment - mode: sync - payload: - resource-assignment-request: - template-prefix: - - vsn - resource-assignment-properties: - nfc-naming-code: vsn - k8s-rb-profile-name: default - service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72 - vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0 - vf-module-model-customization-uuid: 4cac0584-c0d6-42a7-bdb3-29162792e07f - vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718 - vf-module-id: 0cbf558f-5a96-4555-b476-7df8163521aa - aic-cloud-region: k8sregionfour - expectedResponse: - commonHeader: - originatorId: SDNC_DG - requestId: 98397f54-fa57-485f-a04e-1e220b7b1779 - subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b - flags: null - actionIdentifiers: - blueprintName: vFW_CNF_CDS - blueprintVersion: 1.0.45 - actionName: resource-assignment - mode: sync - status: - code: 200 - eventType: EVENT_COMPONENT_EXECUTED - errorMessage: null - message: success - payload: - resource-assignment-response: - meshed-template: - vsn: | - { - "capability-data": [ - { - "capability-name": "generate-name", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "vf_module_name", - "resource-value": "${vf-module-name}" - } - ], - "payload": [ - { - "param-name": "VF_MODULE_TYPE", - "param-value": "vfmt" - }, - { - "param-name": "resource-name", - "param-value": "vf_module_name" - }, - { - "param-name": "resource-value", - "param-value": "${vf-module-name}" - }, - { - "param-name": "external-key", - "param-value": "0cbf558f-5a96-4555-b476-7df8163521aa_vf-module-name" - }, - { - "param-name": "policy-instance-name", - "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP" - }, - { - "param-name": "naming-type", - "param-value": "VF-MODULE" - }, - { - "param-name": "VNF_NAME", - "param-value": "k8sregionfour-onap-nf-20200601t073308018z" - }, - { - "param-name": "VF_MODULE_LABEL", - "param-value": "vsn" - } - ] - } - ] - }, - { - "capability-name": "netbox-ip-assign", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "vsn_onap_private_ip_0", - "resource-value": "${vsn_onap_private_ip_0}" - } - ], - "payload": [ - { - "param-name": "service-instance-id", - "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72" - }, - { - "param-name": "prefix-id", - "param-value": "3" - }, - { - "param-name": "vf_module_id", - "param-value": "0cbf558f-5a96-4555-b476-7df8163521aa" - }, - { - "param-name": "external_key", - "param-value": "0cbf558f-5a96-4555-b476-7df8163521aa-vsn_onap_private_ip_0" - } - ] - } - ] - }, - { - "capability-name": "aai-vf-module-put", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "aai-vf-module-put", - "resource-value": "" - } - ] - } - ] - }, - { - "capability-name": "unresolved-composite-data", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "vsn_name_0", - "resource-value": "${vf_module_name}" - } - ] - } - ] - } - ], - "resource-accumulator-resolved-data": [ - { - "param-name": "vf-module-model-invariant-uuid", - "param-value": "36f25e1b-199b-4de2-b656-c870d341cf0e" - }, - { - "param-name": "vf-module-model-version", - "param-value": "0cbf558f-5a96-4555-b476-7df8163521aa" - }, - { - "param-name": "k8s-rb-profile-name", - "param-value": "default" - }, - { - "param-name": "k8s-rb-profile-namespace", - "param-value": "default" + "k8s-config-template": { + "type": "component-k8s-config-template", + "interfaces": { + "K8sConfigTemplateComponent": { + "operations": { + "process": { + "inputs": { + "artifact-prefix-names": [ + "helm_vpkg" + ], + "resource-assignment-map": { + "get_attribute": [ + "config-setup-process", + "", + "assignment-map", + "config-deploy", + "config-deploy-setup" + ] + } } - ] + } } - - name: resource-assignment for vfw - request: - commonHeader: - originatorId: SDNC_DG - requestId: 98397f54-fa57-485f-a04e-1e220b7b1779 - subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b - actionIdentifiers: - blueprintName: vFW_CNF_CDS - blueprintVersion: 1.0.45 - actionName: resource-assignment - mode: sync - payload: - resource-assignment-request: - template-prefix: - - vfw - resource-assignment-properties: - nfc-naming-code: vfw - k8s-rb-profile-name: default - service-instance-id: 8ead0480-cf44-428e-a4c2-0e6ed10f7a72 - vnf-id: 93b3350d-ed6f-413b-9cc5-a158c1676eb0 - vf-module-model-customization-uuid: 1e123e43-ba40-4c93-90d7-b9f27407ec03 - vnf-model-customization-uuid: 86dc8af4-aa17-4fc7-9b20-f12160d99718 - vf-module-id: '0de4ed56-8b4c-4a2d-8ce6-85d5e269204f ' - aic-cloud-region: k8sregionfour - expectedResponse: - commonHeader: - originatorId: SDNC_DG - requestId: 98397f54-fa57-485f-a04e-1e220b7b1779 - subRequestId: 6bfca5dc-993d-48f1-ad27-a7a9ea91836b - flags: null - actionIdentifiers: - blueprintName: vFW_CNF_CDS - blueprintVersion: 1.0.45 - actionName: resource-assignment - mode: sync - status: - code: 200 - eventType: EVENT_COMPONENT_EXECUTED - errorMessage: null - message: success - payload: - resource-assignment-response: - meshed-template: - vfw: | - { - "capability-data": [ - { - "capability-name": "generate-name", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "vf_module_name", - "resource-value": "${vf-module-name}" - } - ], - "payload": [ - { - "param-name": "VF_MODULE_TYPE", - "param-value": "vfmt" - }, - { - "param-name": "resource-name", - "param-value": "vf_module_name" - }, - { - "param-name": "resource-value", - "param-value": "${vf-module-name}" - }, - { - "param-name": "external-key", - "param-value": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f _vf-module-name" - }, - { - "param-name": "policy-instance-name", - "param-value": "SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP" - }, - { - "param-name": "naming-type", - "param-value": "VF-MODULE" - }, - { - "param-name": "VNF_NAME", - "param-value": "k8sregionfour-onap-nf-20200601t073308018z" - }, - { - "param-name": "VF_MODULE_LABEL", - "param-value": "vfw" - } - ] - } - ] - }, - { - "capability-name": "netbox-ip-assign", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "vfw_onap_private_ip_0", - "resource-value": "${vfw_onap_private_ip_0}" - } - ], - "payload": [ - { - "param-name": "service-instance-id", - "param-value": "8ead0480-cf44-428e-a4c2-0e6ed10f7a72" - }, - { - "param-name": "prefix-id", - "param-value": "3" - }, - { - "param-name": "vf_module_id", - "param-value": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f " - }, - { - "param-name": "external_key", - "param-value": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f -vfw_onap_private_ip_0" - } - ] - } - ] - }, - { - "capability-name": "aai-vf-module-put", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "aai-vf-module-put", - "resource-value": "" - } - ] - } - ] - }, - { - "capability-name": "unresolved-composite-data", - "key-mapping": [ - { - "output-key-mapping": [ - { - "resource-name": "vfw_name_0", - "resource-value": "${vf_module_name}" - } - ] - } - ] - } - ], - "resource-accumulator-resolved-data": [ - { - "param-name": "vf-module-model-invariant-uuid", - "param-value": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817" - }, - { - "param-name": "vf-module-model-version", - "param-value": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f" - }, - { - "param-name": "k8s-rb-profile-name", - "param-value": "default" - }, - { - "param-name": "k8s-rb-profile-namespace", - "param-value": "default" + } + }, + "artifacts": { + "ssh-service-config": { + "type": "artifact-k8sconfig-content", + "file": "Templates/k8s-configs/ssh-service.tar.gz" + }, + "ssh-service-config-customizable": { + "type": "artifact-k8sconfig-content", + "file": "Templates/k8s-configs/ssh-service-config" + }, + "ssh-service-config-customizable-mapping": { + "type": "artifact-mapping-resource", + "file": "Templates/k8s-configs/ssh-service-config/ssh-service-mapping.json" + } + } + } + +The *component-k8s-config-template* that stands behind creation of configuration template has input parameters that can be passed directly (checked in the first order) or can be taken from the *resource-assignment-map* parameter which can be a result of associated *component-resource-resolution* result, like in vFW CNF use case their values are resolved on vf-module level dedicated for *config-assign* and *config-deploy* resource assignment step. The *component-k8s-config-template* inputs are following: + +- k8s-rb-definition-name [string] - (mandatory) the name under which RB definition was created - **VF Module Model Invariant ID** in ONAP +- k8s-rb-definition-version [string] - (mandatory) the version of created RB definition name - **VF Module Model Customization ID** in ONAP +- k8s-rb-config-template-name [string] - (mandatory) the name of the configuration template under which it will be created in k8s plugin. Other parameters are required only when configuration template must be uploaded because it does not exist yet +- k8s-rb-config-template-source [string] - the source of config template content - name of the artifact of the configuration template. When missing, the main definition helm package will be used as a configuration template source (since Jakarta release). +- resource-assignment-map [json] - result of the associated resource assignment step - it may deliver values of inputs if they are not specified directly +- artifact-prefix-names [list<string>] - (mandatory) the list of artifact prefixes like for resource-assigment step in the resource-assigment workflow or its subset + +In our case the *component-k8s-config-template* component receives all the inputs from the dedicated resource-assignment process *config-setup* that is responsible for resolution of all the inputs for configuration templating. This process generates data for *helm_vpkg* prefix and such one is specified in the list of prefixes of the configuration template component. It means that configuration template will be prepared only for vPKG function. + +:: + + "k8s-config-apply": { + "type": "component-k8s-config-value", + "interfaces": { + "K8sConfigValueComponent": { + "operations": { + "process": { + "inputs": { + "artifact-prefix-names": [ + "helm_vpkg" + ], + "k8s-config-operation-type": "create", + "resource-assignment-map": { + "get_attribute": [ + "config-setup-process", + "", + "assignment-map", + "config-deploy", + "config-deploy-setup" + ] + } } - ] + } } - externalServices: - - selector: sdnc - expectations: - - request: - method: GET - path: /restconf/config/GENERIC-RESOURCE-API:services/service/8ead0480-cf44-428e-a4c2-0e6ed10f7a72/service-data/vnfs/vnf/93b3350d-ed6f-413b-9cc5-a158c1676eb0/vnf-data/vnf-topology/vnf-parameters-data/param/vf-naming-policy - responses: - - status: 200 - body: - param: - - name: vf-naming-policy - value: SDNC_Policy.ONAP_NF_NAMING_TIMESTAMP - resource-resolution-data: - capability-name: RA Resolved - status: SUCCESS - headers: - Content-Type: application/json - times: '>= 1' - - -- Verify CBA with UAT + } + }, + "artifacts": { + "ssh-service-default": { + "type": "artifact-k8sconfig-content", + "file": "Templates/k8s-configs/ssh-service-config/values.yaml" + }, + "ssh-service-config": { + "type": "artifact-k8sconfig-content", + "file": "Templates/k8s-configs/ssh-service-values/values.yaml.vtl" + }, + "ssh-service-config-mapping": { + "type": "artifact-mapping-resource", + "file": "Templates/k8s-configs/ssh-service-values/ssh-service-mapping.json" + } + } + } - :: - curl -X POST -u ccsdkapps:ccsdkapps -F cba=@my_cba.zip http://<kube-node>:30499/api/v1/uat/verify +The *component-k8s-config-value* that stands behind creation of configuration instance has input parameters that can be passed directly (checked in the first order) or can be taken from the *resource-assignment-map* parameter which can be a result of associated *component-resource-resolution* result, like in vFW CNF use case their values are resolved on vf-module level dedicated for *config-assign* and *config-deploy*'s' resource-assignment step. The *component-k8s-config-value* inputs are following: + +- k8s-rb-config-name [string] - (mandatory) the name of the configuration template under which it will be created in k8s plugin. Other parameters are required only when configuration template must be uploaded because it does not exist yet +- k8s-rb-config-template-name [string] - (mandatory) the name of the configuration template under which it will be created in k8s plugin. Other parameters are required only when configuration template must be uploaded because it does not exist yet +- k8s-rb-config-value-source [string] - the source of config template content - name of the artifact of the configuration template. If missing *k8s-rb-config-name* is treated as a source +- k8s-rb-config-version [string] - the version of the configuration to restore during the *rollback* operation. First configuratino after *create* has version *1* and new ones, after *update* will have version of the following numbers. When *rollback* operation is performed all previous versions on the path to the desired one are being restored one, by one. (since Jakarta) +- k8s-instance-id [string] - (mandatory) the identifier of the rb instance for which the configuration should be applied +- k8s-config-operation-type [string] - the type of the configuration operation to perform: *create*, *update*, *rollback*, *delete* or *delete_config*. By default *create* operation is performed. *rollback* and *delete_config* types are present since Jakarta release. The *update* operation creates new version of the configuration. *delete* operation creates also new version of configuratino that deletes all the resources in k8s from the cluster. *delete_config* operation aims to delete configuration entirely but it does not delete or update any resources associated with the configuration. +- resource-assignment-map [json] - result of the associated resource assignment step - it may deliver values of inputs if they are not specified directly +- artifact-prefix-names [list<string>] - (mandatory) the list of artifact prefixes like for resource-assigment step in the resource-assigment workflow or its subset -where my_cba.zip is the CBA model with uat.yml (generated in spy step) inside Test folder. +Like for the configuration template, the *component-k8s-config-value* component receives all the inputs from the dedicated resource-assignment process *config-setup* that is responsible for resolution of all the inputs for configuration. This process generates data for *helm_vpkg* prefix and such one is specified in the list of prefixes of the configuration values component. It means that configuration instance will be created only for vPKG function (component allows also update or delete of the configuration but in the vFW CNF case it is used only to create configuration instance). -This verify call failed for us with above uat.yaml file generated in spy. Issue was not investigated further in the scope of this use case. +Finally, `Data Dictionary`_ is also included into demo git directory, re-modeling and making changes into model utilizing CDS model time / runtime is easier as used DD is also known. + +.. note:: CBA of vFW CNF use case is already enriched and VSP of vFW CNF has CBA included inside. In conequence, when VSP is being onboarded into SDC and service is being distributed, CBA is uploaded into CDS. Anyway, CDS contains in the starter dictionary all data dictionary values used in the use case and enrichment of CBA should work as well. Instantiation Overview -...................... +---------------------- + +.. note:: Since Guilin release use case is equipped with automated method **<AUTOMATED>** with python scripts to replace Postman method **<MANUAL>** used in Frankfurt. Nevertheless, Postman collection is good to understand the entire process. If a user selects to follow Postman collection, then automation scripts **must not** be used. **For the entire process use only scripts or only Postman collection**. Both options are described in the further steps of this instruction. The figure below shows all the interactions that take place during vFW CNF instantiation. It's not describing flow of actions (ordered steps) but rather component dependencies. @@ -1576,13 +568,13 @@ The figure below shows all the interactions that take place during vFW CNF insta vFW CNF CDS Use Case Runtime interactions. --------------------------- PART 1 - ONAP Installation --------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~ + 1-1 Deployment components -~~~~~~~~~~~~~~~~~~~~~~~~~ +......................... -In order to run the vFW_CNF_CDS use case, we need ONAP Frankfurt Release (or later) and at least following components: +In order to run the vFW_CNF_CDS use case, we need ONAP Jakarta Release (or later) with at least following components: ======================================================= =========== ONAP Component name Describtion @@ -1590,8 +582,8 @@ ONAP Component name Describtion AAI Required for Inventory Cloud Owner, Customer, Owning Entity, Service, Generic VNF, VF Module SDC VSP, VF and Service Modeling of the CNF DMAAP Distribution of the onboarding package including CBA to all ONAP components -SO Requires for Macro Orchestration using the generic building blocks -CDS Resolution of cloud parameters including Helm override parameters for the CNF. Creation of the multicloud/k8s profile for CNF instantion. +SO Required for Macro Orchestration using the generic building blocks +CDS Resolution of cloud parameters including Helm override parameters for the CNF. Creation of the multicloud/k8s profile for CNF instantion. Creation of configuration template and its instantiation SDNC (needs to include netbox and Naming Generation mS) Provides GENERIC-RESOURCE-API for cloud Instantiation orchestration via CDS. Policy Used to Store Naming Policy AAF Used for Authentication and Authorization of requests @@ -1605,7 +597,7 @@ Shared Maria DB Used as a shared stora ======================================================= =========== 1-2 Deployment -~~~~~~~~~~~~~~ +.............. In order to deploy such an instance, follow the `ONAP Deployment Guide`_ @@ -1692,14 +684,14 @@ And check status of pods, deployments, jobs etc. 1-3 Post Deployment -~~~~~~~~~~~~~~~~~~~ +................... -After completing the first part above, we should have a functional ONAP deployment for the Frankfurt Release. +After completing the first part above, we should have a functional ONAP deployment for the Jakarta Release. -We will need to apply a few modifications to the deployed ONAP Frankfurt instance in order to run the use case. +We will need to apply a few modifications to the deployed ONAP Jakarta instance in order to run the use case. Retrieving logins and passwords of ONAP components -.................................................. +++++++++++++++++++++++++++++++++++++++++++++++++++ Since Frankfurt release hardcoded passwords were mostly removed and it is possible to configure passwords of ONAP components in time of their installation. In order to retrieve these passwords with associated logins it is required to get them with kubectl. Below is the procedure on mariadb-galera DB component example. @@ -1710,10 +702,11 @@ Since Frankfurt release hardcoded passwords were mostly removed and it is possib In this case login is empty as the secret is dedicated to root user. + Postman collection setup -........................ +++++++++++++++++++++++++ -In this demo we have on purpose created all manual ONAP preparation steps (which in real life are automated) by using Postman so it will be clear what exactly is needed. Some of the steps like AAI population is automated by Robot scripts in other ONAP demos (**./demo-k8s.sh onap init**) and Robot script could be used for many parts also in this demo. Later when this demo is fully automated we probably update also Robot scripts to support this demo. +In this demo we have on purpose created all manual ONAP preparation steps (which in real life are automated) by using Postman so it will be clear what exactly is needed. Some of the steps like AAI population is automated by Robot scripts in other ONAP demos (**./demo-k8s.sh onap init**) and Robot script could be used for many parts also in this demo. Postman collection is used also to trigger instantiation using SO APIs. @@ -1769,6 +762,59 @@ You can get the sdnc_port value with kubectl -n onap get svc sdnc -o json | jq '.spec.ports[]|select(.port==8282).nodePort' +Automation Environment Setup +............................ + +Whole content of this use case is stored into single git repository and it contains both the required onboarding information as well as automation scripts for onboarding and instantiation of the use case. + +:: + + git clone --single-branch --branch jakarta "https://gerrit.onap.org/r/demo" + cd demo/heat/vFW_CNF_CDS/templates + +In order to prepare environment for onboarding and instantiation of the use case make sure you have *git*, *make*, *helm* and *pipenv* applications installed. + +The automation scripts are based on `Python SDK`_ and are adopted to automate process of service onboarding, instantiation, deletion and cloud region registration. To configure them for further use: + +:: + + cd demo/heat/vFW_CNF_CDS/automation + +1. Install required packages with +:: + + pipenv pipenv install + +2. Run virtual python environment +:: + + pipenv shell --fancy + +3. Add kubeconfig files, one for ONAP cluster, and one for k8s cluster that will host vFW + +.. note:: Both files can be configured after creation of k8s cluster for vFW instance `2-1 Installation of Managed Kubernetes`_. Make sure that they have configured external IP address properly. If any cluster uses self signed certificates set also *insecure-skip-tls-verify* flag in the config file. + +- artifacts/cluster_kubeconfig - IP address must be reachable by ONAP pods, especially *mutlicloud-k8s* pod + +- artifacts/onap_kubeconfig - IP address must be reachable by automation scripts + +4. Modify config.py file + +- SCENARIO - like described in the `The vFW CNF Use Case`_ section +- NATIVE - when enabled (default) **Native Helm** path will be used, otherwise **Dummy Heat** path will be used (deprecated) +- MACRO_INSTANTIATION - instantiation method used: macro (default) or a'la carte. A'la carte only for the purpose of use with other use cases +- K8S_NAMESPACE - k8s namespace to use for deployment of CNF (vfirewall by default) +- K8S_VERSION - version of the k8s cluster +- K8S_REGION - name of the k8s region from the CLOUD_REGIONS (kud by default) +- CLOUD_REGIONS - configuration of k8s or Openstack regions +- GLOBAL_CUSTOMER_ID - identifier of customer in ONAP +- VENDOR - name of the Vendor in ONAP +- SERVICENAME - **Name of your service model in SDC** +- SKIP_POST_INSTANTIATION - whether post instantiation configuration should be run (it is set indirectly by *SCENARIO*) +- VNF_PARAM_LIST - list of parameters to pass for VNF creation process +- VF_MODULE_PARAM_LIST - list of parameters to pass for VF Module creation + +.. note:: For automation script it is necessary to modify only SCENARIO constant. Other constants may be modified if needed. AAI ... @@ -1777,7 +823,10 @@ Some basic entries are needed in ONAP AAI. These entries are needed ones per ona Create all these entries into AAI in this order. Postman collection provided in this demo can be used for creating each entry. -**Postman -> Initial ONAP setup -> Create** +**<MANUAL>** +:: + + Postman -> Initial ONAP setup -> Create - Create Customer - Create Owning-entity @@ -1787,20 +836,12 @@ Create all these entries into AAI in this order. Postman collection provided in Corresponding GET operations in "Check" folder in Postman can be used to verify entries created. Postman collection also includes some code that tests/verifies some basic issues e.g. gives error if entry already exists. -SO BPMN endpoint fix for VNF adapter requests (v1 -> v2) -........................................................ +**<AUTOMATED>** -SO Openstack adapter needs to be updated to use newer version. Here is also possible improvement area in SO. OpenStack adapter is confusing in context of this use case as VIM is not Openstack but Kubernetes cloud region. In this use case we did not used Openstack at all. - -:: - - kubectl -n onap edit configmap onap-so-bpmn-infra-app-configmap - - .data."override.yaml".mso.adapters.vnf.rest.endpoint: http://so-openstack-adapter.onap:8087/services/rest/v1/vnfs - + .data."override.yaml".mso.adapters.vnf.rest.endpoint: http://so-openstack-adapter.onap:8087/services/rest/v2/vnfs - kubectl -n onap delete pod -l app=so-bpmn-infra +This step is performed jointly with onboarding step `3-2 Onboarding`_ Naming Policy -............. ++++++++++++++ Naming policy is needed to generate unique names for all instance time resources that are wanted to be modeled in the way naming policy is used. Those are normally VNF, VNFC and VF-module names, network names etc. Naming is general ONAP feature and not limited to this use case. @@ -1813,34 +854,15 @@ To check that the naming policy is created and pushed OK, we can run the command .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_ -Network Naming mS -+++++++++++++++++ - -FIXME - Verify if on RC2 this still needs to be performed - -There's a strange feature or bug in naming service still at ONAP Frankfurt and following hack needs to be done to make it work. - -.. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_ - -:: - - # Go into naming service database - kubectl -n onap exec onap-mariadb-galera-0 -it -- mysql -uroot -psecretpassword -D nengdb - select * from EXTERNAL_INTERFACE; - # Delete entries from EXTERNAL_INTERFACE table - delete from EXTERNAL_INTERFACE; - select * from EXTERNAL_INTERFACE; - ---------------------------------------------------- PART 2 - Installation of managed Kubernetes cluster ---------------------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In this demo the target cloud region is a Kubernetes cluster of your choice basically just like with Openstack. ONAP platform is a bit too much hard wired to Openstack and it's visible in many demos. 2-1 Installation of Managed Kubernetes -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +...................................... -In this demo we use Kubernetes deployment used by ONAP multicloud/k8s team to test their plugin features see `KUD readthedocs`_. There's also some outdated instructions in ONAP wiki `KUD in Wiki`_. +In this demo we use Kubernetes deployment used by ONAP multicloud/k8s team to test their plugin features see `KUD github`_. There's also some outdated instructions in ONAP wiki `KUD in Wiki`_. KUD deployment is fully automated and also used in ONAP's CI/CD to automatically verify all `Multicloud k8s gerrit`_ commits (see `KUD Jenkins ci/cd verification`_) and that's quite good (and rare) level of automated integration testing in ONAP. KUD deployemnt is used as it's installation is automated and it also includes bunch of Kubernetes plugins used to tests various k8s plugin features. In addition to deployement, KUD repository also contains test scripts to automatically test multicloud/k8s plugin features. Those scripts are run in CI/CD. @@ -1850,16 +872,24 @@ See `KUD subproject in github`_ for a list of additional plugins this Kubernetes - Multus - Virtlet -Follow instructions in `KUD readthedocs`_ and install target Kubernetes cluster in your favorite machine(s), simplest being just one machine. Your cluster nodes(s) needs to be accessible from ONAP Kuberenetes nodes. +Follow instructions in `KUD github`_ and install target Kubernetes cluster in your favorite machine(s), simplest being just one machine. Your cluster nodes(s) needs to be accessible from ONAP Kuberenetes nodes. Make sure your installed *pip* is of **version < 21.0**. Version 21 do not support python 2.7 that is used in *aio.sh* script. Also to avoid performance problems of your k8s cluster make sure you install only necessary plugins and before running *aio.sh* script execute following command +:: + + export KUD_ADDONS="virtlet ovn4nfv" + +.. warning:: In order to run vFW CNF Use Case deployment test please make sure that this workaround does not have to be applied as well. `KUD Interface Permission`_ 2-2 Cloud Registration -~~~~~~~~~~~~~~~~~~~~~~ +...................... Managed Kubernetes cluster is registered here into ONAP as one cloud region. This obviously is done just one time for this particular cloud. Cloud registration information is kept in AAI. +**<MANUAL>** + Postman collection have folder/entry for each step. Execute in this order. +:: -**Postman -> K8s Cloud Region Registration -> Create** + Postman -> K8s Cloud Region Registration -> Create - Create Complex - Create Cloud Region @@ -1870,15 +900,10 @@ Postman collection have folder/entry for each step. Execute in this order. - Create Availability Zone - Upload Connectivity Info -.. note:: For "Upload Connectivity Info" call you need to provide kubeconfig file of existing KUD cluster. You can find that kubeconfig on deployed KUD in directory `~/.kube/config` and can be easily retrieved e.g. via SCP. Please ensure that kubeconfig contains external IP of K8s cluster in kubeconfig and correct it, if it's not. - -**SO Cloud region configuration** +.. note:: For "Upload Connectivity Info" call you need to provide kubeconfig file of existing KUD cluster. You can find that kubeconfig on deployed KUD in the directory `~/.kube/config` and this file can be easily copied e.g. via SCP. Please ensure that kubeconfig contains external IP of K8s cluster in kubeconfig and correct it, if it's not. SO database needs to be (manually) modified for SO to know that this particular cloud region is to be handled by multicloud. Values we insert needs to obviously match to the ones we populated into AAI. -The related code part in SO is here: `SO Cloud Region Selection`_ -It's possible improvement place in SO to rather get this information directly from AAI. - .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_ :: @@ -1889,124 +914,228 @@ It's possible improvement place in SO to rather get this information directly fr select * from cloud_sites; exit ----------------------------------- +.. note:: The configuration of the new k8s cloud site is documented also here `K8s cloud site config`_ + +**<AUTOMATED>** + +Please copy the kubeconfig file of existing KUD cluster to automation/artifacts/cluster_kubeconfig location `Automation Environment Setup`_ - step **3**. You can find that kubeconfig on deployed KUD in the directory `~/.kube/config` and this file can be easily copied e.g. via SCP. Please ensure that kubeconfig contains external IP of K8s cluster in kubeconfig and correct it, if it's not. + +:: + + python create_cloud_regions.py + PART 3 - Execution of the Use Case ----------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This part contains all the steps to run the use case by using ONAP GUIs, Postman or Python automation scripts. + +3-1 CNF Orchestration Paths in ONAP +................................... -This part contains all the steps to run the use case by using ONAP GUIs and Postman. +Following picture describe the overall sequential flow of the use case for **Native Helm** path (with CNF Adapter) -Following picture describes the overall sequential flow of the use case. +Native Helm CNF Orchestration +............................. -.. figure:: files/vFW_CNF_CDS/vFW_CNF_CDS_Flow.png +Introduced in the Guilin release CNF orchestration method brings native distribution of Helm packages from SDC and native orchestration of CNFs (Helm packages) with SO. SO leverages CNF adapter to interact with K8sPlugin that takes resposnibility for the communication with k8s clusters. Heat templates are not required in the SDC onboarding package and, thanks to the fact that SO knows about Helm package orchestration, synchronization of data between k8s clusters and AAI is possible. Only in this path, since Istanbul release, k8s-resource object is created in relation to tenant, vf-module and generic-vnf objects in AAI. SO CNF adapter is resposobile for synchronization of data between AAI and k8s cluster, however currently it happens only once - after creation of CNF by SO, so any further changes (like new pods) will not be synchronized into AAI. + +.. figure:: files/vFW_CNF_CDS/Native_Helm_Flow.png :align: center - vFW CNF CDS Use Case sequence flow. + vFW CNF CDS Use Case sequence flow for *Native Helm* (Guilin+) path. + -3-1 Onboarding -~~~~~~~~~~~~~~ +Kubernetes and Helm Compatibility +................................. + +K8sPlugin, in the Istanbul release (0.9.x), supports Helm packages that can be validated by Helm 3.5 application. It means that new Helm fetures introduced after Helm 3.5 version are not supported currently. Moreover, since Jakarta release K8sPlugin 0.10.x implementation supports upgrade operation but CNF Upgrade orchestration workflow is not yet fully supported in SO orchestration workflows. In consequence, new service moel cna e distributed with new Helm package over SDC but the Helm upgrade procedure must be performed by direct call to k8sPlugin. The request payload is almost the same liek for Isnatce create but release-name comes for the already created instance. + +:: + + curl -i -X POST http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/{rb-instance-id}/upgrade + +K8sPlugin utilizes also v0.19.4 version of K8s client and its compatibility matrix with k8s clusters can be found here `K8s Client Compatibility`_, Compatibility Matrix section. + +3-2 Onboarding +.............. + +.. note:: Make sure you have performed `Automation Environment Setup`_ steps before following actions here. Creating Onboarding Package -........................... ++++++++++++++++++++++++++++ -Whole content of this use case is stored into single git repository and ONAP user content package of onboarding package can be created with provided Makefile. +Content of the onboarding package can be created with provided Makefile in the *template* folder. -Complete content can be packaged to single onboarding package file in the following way: +Complete content of both Onboarding Packages for **Dummy Heat** and **Native Helm** is packaged to the following VSP onboarding package files: -.. note:: Requires Helm installed +- **Dummy Heat** path: **vfw_k8s_demo.zip** + +- **Native Helm** path: **native_vfw_k8s_demo.zip** + +.. note:: Procedure requires *make* and *helm* applications installed :: - git clone https://gerrit.onap.org/r/demo - cd heat/vFW_CNF_CDS/templates + git clone --single-branch --branch jakarta "https://gerrit.onap.org/r/demo" + cd demo/heat/vFW_CNF_CDS/templates make -The output looks like: +The result of make operation execution is following: :: - mkdir package/ - make -C helm - make[1]: Entering directory '/home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm' - rm -f base_template-*.tgz - rm -f base_template_cloudtech_k8s_charts.tgz - helm package base_template - Successfully packaged chart and saved it to: /home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm/base_template-0.2.0.tgz - mv base_template-*.tgz base_template_cloudtech_k8s_charts.tgz - rm -f vpkg-*.tgz - rm -f vpkg_cloudtech_k8s_charts.tgz - helm package vpkg - Successfully packaged chart and saved it to: /home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm/vpkg-0.2.0.tgz - mv vpkg-*.tgz vpkg_cloudtech_k8s_charts.tgz - rm -f vfw-*.tgz - rm -f vfw_cloudtech_k8s_charts.tgz - helm package vfw - Successfully packaged chart and saved it to: /home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm/vfw-0.2.0.tgz - mv vfw-*.tgz vfw_cloudtech_k8s_charts.tgz - rm -f vsn-*.tgz - rm -f vsn_cloudtech_k8s_charts.tgz - helm package vsn - Successfully packaged chart and saved it to: /home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm/vsn-0.2.0.tgz - mv vsn-*.tgz vsn_cloudtech_k8s_charts.tgz - make[1]: Leaving directory '/home/samuli/onapCode/demo/heat/vFW_CNF_CDS/templates/helm' - mv helm/*.tgz package/ - cp base/* package/ - cd cba/ && zip -r vFW_CDS_CNF.zip . - adding: TOSCA-Metadata/ (stored 0%) - adding: TOSCA-Metadata/TOSCA.meta (deflated 38%) - adding: Templates/ (stored 0%) - adding: Templates/base_template-mapping.json (deflated 92%) - adding: Templates/vfw-template.vtl (deflated 87%) - adding: Templates/nf-params-mapping.json (deflated 86%) - adding: Templates/vsn-mapping.json (deflated 94%) - adding: Templates/vnf-template.vtl (deflated 90%) - adding: Templates/vpkg-mapping.json (deflated 94%) - adding: Templates/vsn-template.vtl (deflated 87%) - adding: Templates/nf-params-template.vtl (deflated 44%) - adding: Templates/base_template-template.vtl (deflated 85%) - adding: Templates/vfw-mapping.json (deflated 94%) - adding: Templates/vnf-mapping.json (deflated 92%) - adding: Templates/vpkg-template.vtl (deflated 86%) - adding: Templates/k8s-profiles/ (stored 0%) - adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%) + make clean + make[1]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates' + rm -rf package_dummy/ + rm -rf package_native/ + rm -rf cba_dummy + rm -f vfw_k8s_demo.zip + rm -f native_vfw_k8s_demo.zip + make[1]: Leaving directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates' + make all + make[1]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates' + mkdir package_dummy/ + mkdir package_native/ + make -C helm + make[2]: Entering directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm' + rm -f base_template-*.tgz + rm -f helm_base_template.tgz + rm -f base_template_cloudtech_k8s_charts.tgz + helm package base_template + Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/base_template-0.2.0.tgz + mv base_template-*.tgz helm_base_template.tgz + cp helm_base_template.tgz base_template_cloudtech_k8s_charts.tgz + rm -f vpkg-*.tgz + rm -f helm_vpkg.tgz + rm -f vpkg_cloudtech_k8s_charts.tgz + helm package vpkg + Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/vpkg-0.2.0.tgz + mv vpkg-*.tgz helm_vpkg.tgz + cp helm_vpkg.tgz vpkg_cloudtech_k8s_charts.tgz + rm -f vfw-*.tgz + rm -f helm_vfw.tgz + rm -f vfw_cloudtech_k8s_charts.tgz + helm package vfw + Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/vfw-0.2.0.tgz + mv vfw-*.tgz helm_vfw.tgz + cp helm_vfw.tgz vfw_cloudtech_k8s_charts.tgz + rm -f vsn-*.tgz + rm -f helm_vsn.tgz + rm -f vsn_cloudtech_k8s_charts.tgz + helm package vsn + Successfully packaged chart and saved it to: /mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm/vsn-0.2.0.tgz + mv vsn-*.tgz helm_vsn.tgz + cp helm_vsn.tgz vsn_cloudtech_k8s_charts.tgz + make[2]: Leaving directory '/mnt/c/Users/advnet/Desktop/SOURCES/demo/heat/vFW_CNF_CDS/templates/helm' + mv helm/helm_*.tgz package_native/ + mv helm/*.tgz package_dummy/ + cp base_dummy/* package_dummy/ + cp base_native/* package_native/ + cp -r cba cba_dummy + sed -i 's/"helm_/"/g' cba_dummy/Definitions/vFW_CNF_CDS.json + cd cba_dummy/ && zip -r CBA.zip . -x pom.xml .idea/\* target/\* + adding: Definitions/ (stored 0%) + adding: Definitions/artifact_types.json (deflated 69%) + adding: Definitions/data_types.json (deflated 88%) + adding: Definitions/node_types.json (deflated 90%) + adding: Definitions/policy_types.json (stored 0%) + adding: Definitions/relationship_types.json (stored 0%) + adding: Definitions/resources_definition_types.json (deflated 94%) + adding: Definitions/vFW_CNF_CDS.json (deflated 87%) adding: Scripts/ (stored 0%) adding: Scripts/kotlin/ (stored 0%) - adding: Scripts/kotlin/KotlinK8sProfileUpload.kt (deflated 75%) adding: Scripts/kotlin/README.md (stored 0%) + adding: Templates/ (stored 0%) + adding: Templates/base_template-mapping.json (deflated 89%) + adding: Templates/base_template-template.vtl (deflated 87%) + adding: Templates/k8s-profiles/ (stored 0%) + adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%) + adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ (stored 0%) + adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/manifest.yaml (deflated 35%) + adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/override_values.yaml (stored 0%) + adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json (deflated 51%) + adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-template.yaml.vtl (deflated 56%) + adding: Templates/nf-params-mapping.json (deflated 88%) + adding: Templates/nf-params-template.vtl (deflated 44%) + adding: Templates/vfw-mapping.json (deflated 89%) + adding: Templates/vfw-template.vtl (deflated 87%) + adding: Templates/vnf-mapping.json (deflated 89%) + adding: Templates/vnf-template.vtl (deflated 93%) + adding: Templates/vpkg-mapping.json (deflated 89%) + adding: Templates/vpkg-template.vtl (deflated 87%) + adding: Templates/vsn-mapping.json (deflated 89%) + adding: Templates/vsn-template.vtl (deflated 87%) + adding: TOSCA-Metadata/ (stored 0%) + adding: TOSCA-Metadata/TOSCA.meta (deflated 37%) + cd cba/ && zip -r CBA.zip . -x pom.xml .idea/\* target/\* adding: Definitions/ (stored 0%) - adding: Definitions/artifact_types.json (deflated 57%) - adding: Definitions/vFW_CNF_CDS.json (deflated 81%) - adding: Definitions/node_types.json (deflated 86%) + adding: Definitions/artifact_types.json (deflated 69%) + adding: Definitions/data_types.json (deflated 88%) + adding: Definitions/node_types.json (deflated 90%) adding: Definitions/policy_types.json (stored 0%) - adding: Definitions/data_types.json (deflated 93%) - adding: Definitions/resources_definition_types.json (deflated 95%) adding: Definitions/relationship_types.json (stored 0%) - mv cba/vFW_CDS_CNF.zip package/ - #Can't use .package extension or SDC will panic - cd package/ && zip -r vfw_k8s_demo.zip . + adding: Definitions/resources_definition_types.json (deflated 94%) + adding: Definitions/vFW_CNF_CDS.json (deflated 87%) + adding: Scripts/ (stored 0%) + adding: Scripts/kotlin/ (stored 0%) + adding: Scripts/kotlin/README.md (stored 0%) + adding: Templates/ (stored 0%) + adding: Templates/base_template-mapping.json (deflated 89%) + adding: Templates/base_template-template.vtl (deflated 87%) + adding: Templates/k8s-profiles/ (stored 0%) + adding: Templates/k8s-profiles/vfw-cnf-cds-base-profile.tar.gz (stored 0%) + adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ (stored 0%) + adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/manifest.yaml (deflated 35%) + adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/override_values.yaml (stored 0%) + adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-mapping.json (deflated 51%) + adding: Templates/k8s-profiles/vfw-cnf-cds-vpkg-profile/ssh-service-template.yaml.vtl (deflated 56%) + adding: Templates/nf-params-mapping.json (deflated 88%) + adding: Templates/nf-params-template.vtl (deflated 44%) + adding: Templates/vfw-mapping.json (deflated 89%) + adding: Templates/vfw-template.vtl (deflated 87%) + adding: Templates/vnf-mapping.json (deflated 89%) + adding: Templates/vnf-template.vtl (deflated 93%) + adding: Templates/vpkg-mapping.json (deflated 89%) + adding: Templates/vpkg-template.vtl (deflated 87%) + adding: Templates/vsn-mapping.json (deflated 89%) + adding: Templates/vsn-template.vtl (deflated 87%) + adding: TOSCA-Metadata/ (stored 0%) + adding: TOSCA-Metadata/TOSCA.meta (deflated 37%) + mv cba/CBA.zip package_native/ + mv cba_dummy/CBA.zip package_dummy/ + cd package_dummy/ && zip -r vfw_k8s_demo.zip . + adding: base_template.env (deflated 22%) + adding: base_template.yaml (deflated 59%) adding: base_template_cloudtech_k8s_charts.tgz (stored 0%) - adding: MANIFEST.json (deflated 83%) - adding: base_template.yaml (deflated 63%) - adding: vsn_cloudtech_k8s_charts.tgz (stored 0%) + adding: CBA.zip (stored 0%) + adding: MANIFEST.json (deflated 84%) + adding: vfw.env (deflated 23%) + adding: vfw.yaml (deflated 60%) adding: vfw_cloudtech_k8s_charts.tgz (stored 0%) + adding: vpkg.env (deflated 13%) + adding: vpkg.yaml (deflated 59%) adding: vpkg_cloudtech_k8s_charts.tgz (stored 0%) - adding: vsn.yaml (deflated 75%) - adding: vpkg.yaml (deflated 76%) - adding: vfw.yaml (deflated 77%) - adding: vFW_CDS_CNF.zip (stored 0%) - adding: base_template.env (deflated 23%) - adding: vsn.env (deflated 53%) - adding: vpkg.env (deflated 55%) - adding: vfw.env (deflated 58%) - mv package/vfw_k8s_demo.zip . + adding: vsn.env (deflated 15%) + adding: vsn.yaml (deflated 59%) + adding: vsn_cloudtech_k8s_charts.tgz (stored 0%) + cd package_native/ && zip -r native_vfw_k8s_demo.zip . + adding: CBA.zip (stored 0%) + adding: helm_base_template.tgz (stored 0%) + adding: helm_vfw.tgz (stored 0%) + adding: helm_vpkg.tgz (stored 0%) + adding: helm_vsn.tgz (stored 0%) + adding: MANIFEST.json (deflated 71%) + mv package_dummy/vfw_k8s_demo.zip . + mv package_native/native_vfw_k8s_demo.zip . $ -and package **vfw_k8s_demo.zip** file is created containing all sub-models. - Import this package into SDC and follow onboarding steps. Service Creation with SDC -......................... ++++++++++++++++++++++++++ + +**<MANUAL>** -Service Creation in SDC is composed of the same steps that are performed by most other use-cases. For reference, you can relate to `vLB use-case`_ +Service Creation in SDC is composed of the same steps that are performed by most other use-cases. For reference, you can look at `vLB use-case`_ Onboard VSP @@ -2015,13 +1144,21 @@ Onboard VSP Create VF and Service Service -> Properties Assignment -> Choose VF (at right box): -- skip_post_instantiation_configuration - True - sdnc_artifact_name - vnf - sdnc_model_name - vFW_CNF_CDS -- sdnc_model_version - K8s 1.0.45 +- sdnc_model_version - 8.0.0 +- skip_post_instantiation_configuration - True + +.. note:: Since Honolulu skip_post_instantiation_configuration flag can be set to *False* if we want to run config-assign/config-deploy operations. + +:: + + python onboarding.py Distribution Of Service -....................... ++++++++++++++++++++++++ + +**<MANUAL>** Distribute service. @@ -2031,22 +1168,23 @@ Verify in SDC UI if distribution was successful. In case of any errors (sometime SDC Catalog database should have our service now defined. - **Postman -> LCM -> [SDC] Catalog Service** - :: - { - "uuid": "64dd38f3-2307-4e0a-bc98-5c2cbfb260b6", - "invariantUUID": "cd1a5c2d-2d4e-4d62-ac10-a5fe05e32a22", - "name": "vfw_cnf_cds_svc", - "version": "1.0", - "toscaModelURL": "/sdc/v1/catalog/services/64dd38f3-2307-4e0a-bc98-5c2cbfb260b6/toscaModel", - "category": "Network L4+", - "lifecycleState": "CERTIFIED", - "lastUpdaterUserId": "cs0008", - "distributionStatus": "DISTRIBUTED" - } + Postman -> LCM -> [SDC] Catalog Service + :: + + { + "uuid": "64dd38f3-2307-4e0a-bc98-5c2cbfb260b6", + "invariantUUID": "cd1a5c2d-2d4e-4d62-ac10-a5fe05e32a22", + "name": "vfw_cnf_cds_svc", + "version": "1.0", + "toscaModelURL": "/sdc/v1/catalog/services/64dd38f3-2307-4e0a-bc98-5c2cbfb260b6/toscaModel", + "category": "Network L4+", + "lifecycleState": "CERTIFIED", + "lastUpdaterUserId": "cs0008", + "distributionStatus": "DISTRIBUTED" + } Listing should contain entry with our service name **vfw_cnf_cds_svc**. @@ -2056,105 +1194,110 @@ Verify in SDC UI if distribution was successful. In case of any errors (sometime SO Catalog database should have our service NFs defined now. - **Postman -> LCM -> [SO] Catalog DB Service xNFs** + :: + + Postman -> LCM -> [SO] Catalog DB Service xNFs :: + { + "serviceVnfs": [ { - "serviceVnfs": [ + "modelInfo": { + "modelName": "VfVfwK8sDemoCnfMc202109231", + "modelUuid": "70edaca8-8c79-468a-aa76-8224cfe686d0", + "modelInvariantUuid": "7901fc89-a94d-434a-8454-1e27b99dc0e2", + "modelVersion": "1.0", + "modelCustomizationUuid": "86dc8af4-aa17-4fc7-9b20-f12160d99718", + "modelInstanceName": "vfw_cnf_cds_vsp 0" + }, + "toscaNodeType": "org.openecomp.resource.vf.VfwCnfCdsVsp", + "nfFunction": null, + "nfType": null, + "nfRole": null, + "nfNamingCode": null, + "multiStageDesign": "false", + "vnfcInstGroupOrder": null, + "resourceInput": "TBD", + "vfModules": [ { "modelInfo": { - "modelName": "vfw_cnf_cds_vsp", - "modelUuid": "70edaca8-8c79-468a-aa76-8224cfe686d0", - "modelInvariantUuid": "7901fc89-a94d-434a-8454-1e27b99dc0e2", - "modelVersion": "1.0", - "modelCustomizationUuid": "86dc8af4-aa17-4fc7-9b20-f12160d99718", - "modelInstanceName": "vfw_cnf_cds_vsp 0" + "modelName": "VfVfwK8sDemoCnfMc202109231..helm_base_template..module-4", + "modelUuid": "a9f5d65f-20c3-485c-8cf9-eda9ea94300e", + "modelInvariantUuid": "7888f606-3ee8-4edb-b96d-467fead6ee4f", + "modelVersion": "1", + "modelCustomizationUuid": "b9faba47-d03d-4ba1-a117-4c19632b2136" }, - "toscaNodeType": "org.openecomp.resource.vf.VfwCnfCdsVsp", - "nfFunction": null, - "nfType": null, - "nfRole": null, - "nfNamingCode": null, - "multiStageDesign": "false", - "vnfcInstGroupOrder": null, - "resourceInput": "TBD", - "vfModules": [ - { - "modelInfo": { - "modelName": "VfwCnfCdsVsp..base_template..module-0", - "modelUuid": "274f4bc9-7679-4767-b34d-1df51cdf2496", - "modelInvariantUuid": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423", - "modelVersion": "1", - "modelCustomizationUuid": "b27fad11-44da-4840-9256-7ed8a32fbe3e" - }, - "isBase": true, - "vfModuleLabel": "base_template", - "initialCount": 1, - "hasVolumeGroup": false - }, - { - "modelInfo": { - "modelName": "VfwCnfCdsVsp..vsn..module-1", - "modelUuid": "0cbf558f-5a96-4555-b476-7df8163521aa", - "modelInvariantUuid": "36f25e1b-199b-4de2-b656-c870d341cf0e", - "modelVersion": "1", - "modelCustomizationUuid": "4cac0584-c0d6-42a7-bdb3-29162792e07f" - }, - "isBase": false, - "vfModuleLabel": "vsn", - "initialCount": 0, - "hasVolumeGroup": false - }, - { - "modelInfo": { - "modelName": "VfwCnfCdsVsp..vpkg..module-2", - "modelUuid": "011b5f61-6524-4789-bd9a-44cfbf321463", - "modelInvariantUuid": "4e2b9975-5214-48b8-861a-5701c09eedfa", - "modelVersion": "1", - "modelCustomizationUuid": "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb" - }, - "isBase": false, - "vfModuleLabel": "vpkg", - "initialCount": 0, - "hasVolumeGroup": false - }, - { - "modelInfo": { - "modelName": "VfwCnfCdsVsp..vfw..module-3", - "modelUuid": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f", - "modelInvariantUuid": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817", - "modelVersion": "1", - "modelCustomizationUuid": "1e123e43-ba40-4c93-90d7-b9f27407ec03" - }, - "isBase": false, - "vfModuleLabel": "vfw", - "initialCount": 0, - "hasVolumeGroup": false - } - ], - "groups": [] + "isBase": false, + "vfModuleLabel": "base_template", + "initialCount": 1, + "hasVolumeGroup": false + }, + { + "modelInfo": { + "modelName": "VfVfwK8sDemoCnfMc202109293..helm_vsn..module-1", + "modelUuid": "8e72ed23-4842-471a-ad83-6a4d285c48e1", + "modelInvariantUuid": "4f5a8a02-0dc6-4387-b86e-bd352f711e18", + "modelVersion": "1", + "modelCustomizationUuid": "ab5614d6-25c2-4863-bad3-93e354b4d5ba" + }, + "isBase": false, + "vfModuleLabel": "vsn", + "initialCount": 0, + "hasVolumeGroup": false + }, + { + "modelInfo": { + "modelName": "VfVfwK8sDemoCnfMc202109293..helm_vpkg..module-2", + "modelUuid": "64f9d622-a8c1-4992-ba35-abdc13f87660", + "modelInvariantUuid": "88d8d71a-30c9-4e00-a6b9-bd86bae7ed37", + "modelVersion": "1", + "modelCustomizationUuid": "37ab4199-19aa-4f63-9a11-d31b8c25ce46" + }, + "isBase": false, + "vfModuleLabel": "vpkg", + "initialCount": 0, + "hasVolumeGroup": false + }, + { + "modelInfo": { + "modelName": "VfVfwK8sDemoCnfMc202109293..helm_vfw..module-3", + "modelUuid": "f6f62096-d5cc-474e-82c7-655e7d6628b2", + "modelInvariantUuid": "6077ce70-3a1d-47e6-87a0-6aed6a29b089", + "modelVersion": "1", + "modelCustomizationUuid": "879cda5e-7af9-43d2-bd6c-50e330ab328e" + }, + "isBase": false, + "vfModuleLabel": "vfw", + "initialCount": 0, + "hasVolumeGroup": false } - ] + ], + "groups": [] } + ] + } + +.. note:: For **Native Helm** path both modelName will have prefix *helm_* i.e. *helm_vfw* and vfModuleLabel will have *helm_* keyword inside i.e. *VfVfwK8sDemoCnfMc202109293..helm_vfw..module-3* - SDNC: - SDNC should have it's database updated with sdnc_* properties that were set during service modeling. + SDNC should have it's database updated with *sdnc_* properties that were set during service modeling. .. note:: Please change credentials respectively to your installation. The required credentials can be retrieved with instruction `Retrieving logins and passwords of ONAP components`_ - :: - kubectl -n onap exec onap-mariadb-galera-0 -it -- sh - mysql -uroot -psecretpassword -D sdnctl - MariaDB [sdnctl]> select sdnc_model_name, sdnc_model_version, sdnc_artifact_name from VF_MODEL WHERE customization_uuid = '86dc8af4-aa17-4fc7-9b20-f12160d99718'; - +-----------------+--------------------+--------------------+ - | sdnc_model_name | sdnc_model_version | sdnc_artifact_name | - +-----------------+--------------------+--------------------+ - | vFW_CNF_CDS | 1.0.45 | vnf | - +-----------------+--------------------+--------------------+ - 1 row in set (0.00 sec) +:: + + kubectl -n onap exec onap-mariadb-galera-0 -it -- sh + mysql -uroot -psecretpassword -D sdnctl + MariaDB [sdnctl]> select sdnc_model_name, sdnc_model_version, sdnc_artifact_name from VF_MODEL WHERE customization_uuid = '86dc8af4-aa17-4fc7-9b20-f12160d99718'; + +-----------------+--------------------+--------------------+ + | sdnc_model_name | sdnc_model_version | sdnc_artifact_name | + +-----------------+--------------------+--------------------+ + | vFW_CNF_CDS | 8.0.0 | vnf | + +-----------------+--------------------+--------------------+ + 1 row in set (0.00 sec) .. note:: customization_uuid value is the modelCustomizationUuid of the VNF (serviceVnfs response in 2nd Postman call from SO Catalog DB) @@ -2163,7 +1306,9 @@ Verify in SDC UI if distribution was successful. In case of any errors (sometime CDS should onboard CBA uploaded as part of VF. - **Postman -> Distribution Verification -> [CDS] List CBAs** + :: + + Postman -> Distribution Verification -> [CDS] List CBAs :: @@ -2173,14 +1318,14 @@ Verify in SDC UI if distribution was successful. In case of any errors (sometime "id": "c505e516-b35d-4181-b1e2-bcba361cfd0a", "artifactUUId": null, "artifactType": "SDNC_MODEL", - "artifactVersion": "1.0.45", - "artifactDescription": "Controller Blueprint for vFW_CNF_CDS:1.0.45", + "artifactVersion": "8.0.0", + "artifactDescription": "Controller Blueprint for vFW_CNF_CDS:8.0.0", "internalVersion": null, "createdDate": "2020-05-29T06:02:20.000Z", "artifactName": "vFW_CNF_CDS", - "published": "Y", + "published": "N", "updatedBy": "Samuli Silvius <s.silvius@partner.samsung.com>", - "tags": "Samuli Silvius, vFW_CNF_CDS" + "tags": "Samuli Silvius, Lukasz Rajewski, vFW_CNF_CDS" } } ] @@ -2190,72 +1335,107 @@ Verify in SDC UI if distribution was successful. In case of any errors (sometime - sdnc_model_name == artifactName - sdnc_model_version == artifactVersion - You can also use **Postman -> Distribution Verification -> [CDS] CBA Download** to download CBA for further verification but it's fully optional. + You can also use Postman to download CBA for further verification but it's fully optional. + + :: + + Postman -> Distribution Verification -> [CDS] CBA Download - K8splugin: K8splugin should onboard 4 resource bundles related to helm resources: - **Postman -> Distribution Verification -> [K8splugin] List Resource Bundle Definitions** + :: + + Postman -> Distribution Verification -> [K8splugin] List Resource Bundle Definitions :: [ - { - "rb-name": "52842255-b7be-4a1c-ab3b-2bd3bd4a5423", - "rb-version": "274f4bc9-7679-4767-b34d-1df51cdf2496", - "chart-name": "base_template", - "description": "", - "labels": { - "vnf_customization_uuid": "b27fad11-44da-4840-9256-7ed8a32fbe3e" - } - }, - { - "rb-name": "36f25e1b-199b-4de2-b656-c870d341cf0e", - "rb-version": "0cbf558f-5a96-4555-b476-7df8163521aa", - "chart-name": "vsn", - "description": "", - "labels": { - "vnf_customization_uuid": "4cac0584-c0d6-42a7-bdb3-29162792e07f" - } - }, - { - "rb-name": "4e2b9975-5214-48b8-861a-5701c09eedfa", - "rb-version": "011b5f61-6524-4789-bd9a-44cfbf321463", - "chart-name": "vpkg", - "description": "", - "labels": { - "vnf_customization_uuid": "4e7028a1-4c80-4d20-a7a2-a1fb3343d5cb" - } - }, - { - "rb-name": "9ffda670-3d77-4f6c-a4ad-fb7a09f19817", - "rb-version": "0de4ed56-8b4c-4a2d-8ce6-85d5e269204f", - "chart-name": "vfw", - "description": "", - "labels": { - "vnf_customization_uuid": "1e123e43-ba40-4c93-90d7-b9f27407ec03" - } + { + "rb-name": "a9f5d65f-20c3-485c-8cf9-eda9ea94300e", + "rb-version": "b9faba47-d03d-4ba1-a117-4c19632b2136", + "chart-name": "base_template", + "description": "", + "labels": { + "vf_module_model_name": "VfVfwK8sDemoCnfMc202109231..helm_base_template..module-4", + "vf_module_model_uuid": "7888f606-3ee8-4edb-b96d-467fead6ee4f" + } + }, + { + "rb-name": "f6f62096-d5cc-474e-82c7-655e7d6628b2", + "rb-version": "879cda5e-7af9-43d2-bd6c-50e330ab328e", + "chart-name": "vfw", + "description": "", + "labels": { + "vf_module_model_name": "VfVfwK8sDemoCnfMc202109293..helm_vfw..module-3", + "vf_module_model_uuid": "6077ce70-3a1d-47e6-87a0-6aed6a29b089" + } + }, + { + "rb-name": "8e72ed23-4842-471a-ad83-6a4d285c48e1", + "rb-version": "ab5614d6-25c2-4863-bad3-93e354b4d5ba", + "chart-name": "vsn", + "description": "", + "labels": { + "vf_module_model_name": "VfVfwK8sDemoCnfMc202109293..helm_vsn..module-1", + "vf_module_model_uuid": "4f5a8a02-0dc6-4387-b86e-bd352f711e18" } + }, + { + "rb-name": "64f9d622-a8c1-4992-ba35-abdc13f87660", + "rb-version": "37ab4199-19aa-4f63-9a11-d31b8c25ce46", + "chart-name": "vpkg", + "description": "", + "labels": { + "vf_module_model_name": "VfVfwK8sDemoCnfMc202109293..helm_vpkg..module-2", + "vf_module_model_uuid": "88d8d71a-30c9-4e00-a6b9-bd86bae7ed37" + } + } ] -3-2 CNF Instantiation -~~~~~~~~~~~~~~~~~~~~~ +**<AUTOMATED>** + +Distribution is a part of the onboarding step and at this stage is performed + +3-3 CNF Instantiation +..................... This is the whole beef of the use case and furthermore the core of it is that we can instantiate any amount of instances of the same CNF each running and working completely of their own. Very basic functionality in VM (VNF) side but for Kubernetes and ONAP integration this is the first milestone towards other normal use cases familiar for VNFs. -Use again Postman to trigger instantion from SO interface. Postman collection is automated to populate needed parameters when queries are run in correct order. If you did not already run following 2 queries after distribution (to verify distribution), run those now: +**<MANUAL>** -- **Postman -> LCM -> 1.[SDC] Catalog Service** -- **Postman -> LCM -> 2. [SO] Catalog DB Service xNFs** +Postman collection is automated to populate needed parameters when queries are run in correct order. If you did not already run following 2 queries after distribution (to verify distribution), run those now: + +:: + + Postman -> LCM -> 1.[SDC] Catalog Service + +:: + + Postman -> LCM -> 2. [SO] Catalog DB Service xNFs Now actual instantiation can be triggered with: -**Postman -> LCM -> 3. [SO] Self-Serve Service Assign & Activate** +:: + + Postman -> LCM -> 3. [SO] Self-Serve Service Assign & Activate + +**<AUTOMATED>** -Follow progress with SO's GET request: +Required inputs for instantiation process are taken from the *config.py* file. +:: + + python instantiation.py + + +Finally, to follow the progress of instantiation request with SO's GET request: + +**<MANUAL>** -**Postman -> LCM -> 4. [SO] Infra Active Requests** +:: + + Postman -> LCM -> 4. [SO] Infra Active Requests The successful reply payload in that query should start like this: @@ -2295,26 +1475,47 @@ The successful reply payload in that query should start like this: } -Progress can be followed also with `SO Monitoring`_ dashboard. +Progress can be also followed also with `SO Monitoring`_ dashboard. -.. note:: In Frankfurt release *SO Monitoring* dashboard was removed from officail release and before it can be used it must be exposed and default user credentials must be configured +Service Instance Termination +++++++++++++++++++++++++++++ +Service instance can be terminated with the following postman call: -You can finally terminate this instance (now or later) with another call: +**<MANUAL>** +:: -**Postman -> LCM -> 5. [SO] Service Delete** + Postman -> LCM -> 5. [SO] Service Delete + +**<AUTOMATED>** +:: -Second instance Instantion -.......................... + python delete.py + +.. note:: Automated service deletion mecvhanism takes information about the instantiated service instance from the *config.py* file and *SERVICE_INSTANCE_NAME* variable. If you modify this value before the deletion of existing service instance then you will loose opportunity to easy delete already created service instance. + +Second Service Instance Instantiation ++++++++++++++++++++++++++++++++++++++ To finally verify that all the work done within this demo, it should be possible to instantiate second vFW instance successfully. Trigger new instance createion. You can use previous call or a separate one that will utilize profile templating mechanism implemented in CBA: -**Postman -> LCM -> 6. [SO] Self-Serve Service Assign & Activate - Second** +**<MANUAL>** +:: -3-3 Results and Logs -~~~~~~~~~~~~~~~~~~~~ + Postman -> LCM -> 6. [SO] Self-Serve Service Assign & Activate - Second + +**<AUTOMATED>** + +Before second instance of service is created you need to modify *config.py* file changing the *SERVICENAME* and *SERVICE_INSTANCE_NAME* to different values and by changing the value or *k8s-rb-profile-name* parameter for *vpg* module from value *default* or *vfw-cnf-cds-base-profile* to *vfw-cnf-cds-vpkg-profile* what will result with instantiation of additional ssh service for *vpg* module. Second onboarding in automated case is required due to the existing limitations of *python-sdk* librarier that create vf-module instance name base on the vf-module model name. For manual Postman option vf-module instance name is set on service instance name basis what makes it unique. +:: + + python onboarding.py + python instantiation.py + +3-4 Results and Logs +.................... Now multiple instances of Kubernetes variant of vFW are running in target VIM (KUD deployment). @@ -2323,9 +1524,13 @@ Now multiple instances of Kubernetes variant of vFW are running in target VIM (K vFW Instance In Kubernetes +**<MANUAL>** + To review situation after instantiation from different ONAP components, most of the info can be found using Postman queries provided. For each query, example response payload(s) is/are saved and can be found from top right corner of the Postman window. -**Postman -> Instantiation verification** +:: + + Postman -> Instantiation verification** Execute example Postman queries and check example section to see the valid results. @@ -2342,8 +1547,6 @@ K8S Instances in KUD **Postman -> Instantiation verification -> [K8splu Query also directly from VIM: -FIXME - needs updated output with newest naming policy - :: # @@ -2392,26 +1595,32 @@ FIXME - needs updated output with newest naming policy Component Logs From The Execution -................................. ++++++++++++++++++++++++++++++++++ -All logs from the use case execution are here: +**<MANUAL>** - :download:`logs <files/vFW_CNF_CDS/logs.zip>` +All logs from the use case execution can be retrieved with following -- `so-bpmn-infra_so-bpmn-infra_debug.log` -- SO openstack adapter -- `sdnc_sdnc_karaf.log` +:: + + kubectl -n onap logs `kubectl -n onap get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}' | grep -m1 <COMPONENT_NAME>` -c <CONTAINER> + +where <COMPONENT_NAME> and <CONTAINER> should be replaced with following keywords respectively: + +- so-bpmn-infra, so-bpmn-infra +- so-openstack-adapter, so-openstack-adapter +- so-cnf-adapter, so-cnf-adapter +- sdnc-0, sdnc From karaf.log all requests (payloads) to CDS can be found by searching following string: ``'Sending request below to url http://cds-blueprints-processor-http:8080/api/v1/execution-service/process'`` -- `cds-blueprints-processor_cds-blueprints-processor_POD_LOG.log` -- `multicloud-k8s_multicloud-k8s_POD_LOG.log` -- network naming +- cds-blueprints-processor, cds-blueprints-processor +- multicloud-k8s, multicloud-k8s +- network-name-gen, network-name-gen, -Debug log -+++++++++ +**Debug log** In case more detailed logging is needed, here's instructions how to setup DEBUG logging for few components. @@ -2437,62 +1646,258 @@ In case more detailed logging is needed, here's instructions how to setup DEBUG # Delete the Pods to make changes effective kubectl -n onap delete pods -l app=cds-blueprints-processor ------------------------------------------------ -PART 4 - Summary and Future improvements needed ------------------------------------------------ +3-5 Verification of the CNF Status +.................................. + +**<MANUAL>** + +The Guilin introduced new API for verification of the status of instantiated resources in k8s cluster. The API gives result similar to *kubectl describe* operation for all the resources created for particular *rb-definition*. Status API can be used to verify the k8s resources after instantiation but also can be used leveraged for synchronization of the information with external components, like AAI. To use Status API call + +:: + + curl -i http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/{rb-instance-id}/status + +where {rb-instance-id} can be taken from the list of instances resolved the following call or from AAI *heat-stack-id* property of created *vf-module* associated with each Helm package from onboarded VSP which holds the *rb-instance-id* value. + +The same API can be accessed over cnf-adapter endpoint (ClusterIP): + +:: + + curl -i http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/{rb-instance-id}/status + +The similar to Status API is Query API, avaialble since Honolulu, that allows to fetch specific resources that belong to the created instance. The Query API allows to filter resources by Name, Kind, APiVersion, Namespace and Labels. The k8splugin endpoint is: + +:: + + curl -i http://${K8S_NODE_IP}:30280/api/multicloud-k8s/v1/v1/instance/{rb-instance-id}/query?ApiVersion=v1&Kind=Deployment&Name=vfw-1-vfw&Namespace=vfirewall + +and cnf-adapter endpoint is: + +:: + + curl -i http://${K8S_NODE_IP}:8090/api/cnf-adapter/v1/instance/{rb-instance-id}/query?ApiVersion=v1&Kind=Deployment&Name=vfw-1-vfw&Namespace=vfirewall + + +Examplary output of Status API is shown below (full result of test vFW CNF helm package in the attached file). It shows the list of GVK resources created for requested *rb-instance* (Helm and vf-module in the same time) with assocated describe result for all of them. + + :download:`Full Status API Result <files/vFW_CNF_CDS/status-response.json>` + +:: + + { + "request": { + "rb-name": "vfw", + "rb-version": "plugin_test", + "profile-name": "test_profile", + "release-name": "", + "cloud-region": "kud", + "labels": { + "testCaseName": "plugin_fw.sh" + }, + "override-values": { + "global.onapPrivateNetworkName": "onap-private-net-test" + } + }, + "ready": true, + "resourceCount": 1, + "resourcesStatus": [ + { + "name": "sink-configmap", + "GVK": { + "Group": "", + "Version": "v1", + "Kind": "ConfigMap" + }, + "status": { + "apiVersion": "v1", + "data": { + "protected_net_gw": "192.168.20.100", + "protected_private_net_cidr": "192.168.10.0/24" + }, + "kind": "ConfigMap", + "metadata": { + "creationTimestamp": "2020-09-29T13:36:25Z", + "labels": { + "k8splugin.io/rb-instance-id": "practical_nobel" + }, + "name": "sink-configmap", + "namespace": "plugin-tests-namespace", + "resourceVersion": "10720771", + "selfLink": "/api/v1/namespaces/plugin-tests-namespace/configmaps/sink-configmap", + "uid": "46c8bec4-980c-455b-9eb0-fb84ac8cc450" + } + } + } + ] + } + +**<AUTOMATED>** + +Since Honolulu release vFW CNF Use Case is equipped with dedicated mechanisms for verification of the CNF status automatically, during the instantiation. The process utilizes the k8sPlugin Status and Healthcheck APIs that both are natively exposed in the CDS and can be executed from the script execution functionality in the CDS. + +.. figure:: files/vFW_CNF_CDS/healthcheck.png + :scale: 60 % + :align: center + + vFW CNF Healthcheck flow concept + +There is exposed a dedicated workflow in CBA, where Status API result verification is run with *status-verification-script* step and execution of the healthcheck job is run with *health-check-process*. The first one verifies if all pods have *Running* state. If yes, then verification of the health is started by execution of the dedicated Helm tests which are a jobs that verify connectivity in each component. + +:: + + "health-check": { + "steps": { + "config-setup": { + "description": "Gather necessary input for config init and status verification", + "target": "config-setup-process", + "activities": [ + { + "call_operation": "ResourceResolutionComponent.process" + } + ], + "on_success": [ + "config-apply" + ], + "on_failure": [ + "handle_error" + ] + }, + "status-verification-script": { + "description": "Simple status verification script", + "target": "simple-status-check", + "activities": [ + { + "call_operation": "ComponentScriptExecutor.process" + } + ], + "on_success": [ + "health-check-process" + ], + "on_failure": [ + "handle_error" + ] + }, + "health-check-process": { + "description": "Start health check script", + "target": "health-check-script", + "activities": [ + { + "call_operation": "ComponentScriptExecutor.process" + } + ], + "on_success": [ + "collect-results" + ], + "on_failure": [ + "handle_error" + ] + }, + "handle_error": { + "description": "Simple error verification script", + "target": "simple-error-check", + "activities": [ + { + "call_operation": "ComponentScriptExecutor.process" + } + ], + "on_success": [ + "collect-results" + ] + }, + "collect-results": { + "description": "Final collection of results", + "target": "collect-results" + } + }, + + +Since Istanbul release, SO is equipped with dedicated workflow for verification of the CNF status. It works similarly to the workflow introduced in Honolulu, however basic CNF Status Verification step utilizes "Ready" flag of the StatusAPI response to check if k8s resources created from Helm package are up and running. Ready flag works properly in k8splugin 0.9.1 or higher. Both operations are performed by ControllerExecutionBB in SO and are realized by cnf-adapter component in SO. This workflow can be triggered by a dedicated endpoint documented here: `CNF Health Check`_. This workflow is not yet integrated into automation scripts. + +3-6 Synchronization of created k8s resources into AAI +..................................................... + +Since Istanbul release `AAI v24 schema`_ version is used to store basic information about k8s resources deployed from each helm package. The AAI change is described in `K8s Resource in AAI`_. The information stored in AAI lets to identify all the deployed k8s resoureces but the details about them have to be fetched from the k8s cluster on demand. Such design is motivated by high frequency of k8s resource status change and the plethora of resource types avaialble in k8s - including the CRDs that extend the predefined resource types available in k8s. In consequence, there was no sense to store in AAI full runtime picture of the k8s resources as the synchronization of them would be impossible. + +K8s-Resource object is stored in the cloud-infrastructure set of AAI APIs and it belongs to the tenant, and is related with both generic-vnf and vf-module. Each k8s-resource object created in AAI has selflink for cnf-adapter Query API, described in `3-5 Verification of the CNF Status`_, that allows to fetch actual information about the resource in k8s. The examplary set of k8s-resources with related generic-vnf and vf-modules for vFW CNF use case is in the files attached below. + + :download:`List of K8s Resources <files/vFW_CNF_CDS/k8s-resources-response.json>` + + :download:`Generic VNF with modules <files/vFW_CNF_CDS/vfw-generic-vnf-aai.json>` + + :download:`vPKG VF-Module with related k8s-resource relations <files/vFW_CNF_CDS/vpkg-vf-module-aai.json>` + +AAI synchronization is run just after creation of the vf-module by SO. Since Jakarta release, cnf-adapter synchronizes into AAI information about any change on k8s resources performed after their initial creation. For instance, if pod is deleted in k8s cluster, the new one is automatically created. In consequence, K8sPlugin sends notification about the change to cnf-adapter, and the latter one performs update of the information in AAI by removing the old pod and creating the new one in AAI. The update in AAI, after the change in k8s cluster, should by applied with no more than 30s delay. + +In order to force an imidiate update of AAI information about the concrete Helm package, the following API can be also used with properly modified body (all except the callbackUrl). + +:: + + curl -i -X POST http://${K8S_NODE_IP}:8090/api/cnf-adapter/v1/aai-update + + +:: + + { + "instanceId": "keen_darwin", + "cloudRegion": "kud", + "cloudOwner": "K8sCloudOwner", + "tenantId": "dca807fa-0d3e-4fb1-85eb-b9e1c03108a3", + "callbackUrl": "http://example", + "genericVnfId": "8b3af2e0-fd66-460d-b928-22f5dac517a6", + "vfModuleId": "a0161551-9d13-47c2-ba4f-896d4ee401d4" + } + -This use case made CNFs onboarding and instantiation a little bit easier and closer to "normal" VNF way. Also CDS resource resolution capabilities were taken into use (compared to earlier demos) together with SO's MACRO workflow. +PART 4 - Future improvements needed +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -CNF application in vFW (Helm charts) were divided to multiple Helm charts comply with vf-module structure of a Heat based VNF. +Future development areas for this use case: -Future development areas for this use case and in general for CNF support could be: +- Include Closed Loop part of the vFW CNF demo. +- vFW service with Openstack VNF (KUD) and Kubernetes CNF -- Automate manual initialization steps in to Robot init. Now all was done with Postman or manual step on command line. -- Automate use case in ONAP daily CI -- Include Closed Loop part of the vFW demo. -- Use multicloud/k8S API v2. Also consider profile concept future. -- Sync CDS model with `vFW_CNF_CDS Model`_ use case i.e. try to keep only single model regardless of xNF being Openstack or Kubernetes based. -- TOSCA based service and xNF models instead of dummy Heat wrapper. Won't work directly with current vf-module oriented SO workflows. -- vFW service with Openstack VNF and Kubernetes CNF -- Post instantiation configuration with Day 2 configuration APIs of multicloud/k8S API -- Auto generation of instantiation specific helm resources in CDS and their population through profiles +Future development areas for CNF support: +- Extraction of override values in time of the package onboarding +- Upgrade of the vFW CNF similar to Helm Upgrade through the SDC and SO +- Use multicloud/k8S API v2 (EMCO) -Multiple lower level bugs/issues were also found during use case development +Some of the features from the list above are covered by the Jakarta roadmap described in `REQ-890`_. -- Distribution of Helm package directly from onboarding package `SDC-2776`_ -- CDS: UAT testing is broken `CCSDK-2155`_ -.. _ONAP Deployment Guide: https://docs.onap.org/en/frankfurt/submodules/oom.git/docs/oom_quickstart_guide.html#quick-start-label -.. _CDS Modeling Concepts: https://wiki.onap.org/display/DW/Modeling+Concepts +.. _ONAP Deployment Guide: https://docs.onap.org/projects/onap-oom/en/latest/sections/guides/deployment_guides/oom_deployment.html +.. _CDS Documentation: https://docs.onap.org/projects/onap-ccsdk-cds/en/latest/ .. _vLB use-case: https://wiki.onap.org/pages/viewpage.action?pageId=71838898 -.. _vFW_CNF_CDS Model: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS?h=frankfurt +.. _vFW_CNF_CDS Model: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates?h=guilin +.. _vFW_CNF_CDS Automation: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/automation?h=guilin .. _vFW CDS Dublin: https://wiki.onap.org/display/DW/vFW+CDS+Dublin -.. _vFW CBA Model: https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/service-blueprint/vFW?h=frankfurt +.. _vFW CBA Model: https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/service-blueprint/vFW?h=elalto .. _vFW_Helm Model: https://git.onap.org/multicloud/k8s/tree/kud/demo/firewall?h=elalto .. _vFW_NextGen: https://git.onap.org/demo/tree/heat/vFW_NextGen?h=elalto -.. _vFW EDGEX K8S: https://onap.readthedocs.io/en/elalto/submodules/integration.git/docs/docs_vfw_edgex_k8s.html +.. _vFW EDGEX K8S: https://docs.onap.org/projects/onap-integration/en/latest/docs_vfw_edgex_k8s.html .. _vFW EDGEX K8S In ONAP Wiki: https://wiki.onap.org/display/DW/Deploying+vFw+and+EdgeXFoundry+Services+on+Kubernets+Cluster+with+ONAP -.. _KUD readthedocs: https://docs.onap.org/en/frankfurt/submodules/multicloud/k8s.git/docs +.. _KUD github: https://github.com/onap/multicloud-k8s/tree/honolulu/kud/hosting_providers/baremetal .. _KUD in Wiki: https://wiki.onap.org/display/DW/Kubernetes+Baremetal+deployment+setup+instructions -.. _Multicloud k8s gerrit: https://gerrit.onap.org/r/q/status:open+project:+multicloud/k8 -.. _KUD subproject in github: https://github.com/onap/multicloud-k8s/tree/master/kud +.. _Multicloud k8s gerrit: https://gerrit.onap.org/r/q/status:open+project:+multicloud/k8s +.. _KUD subproject in github: https://github.com/onap/multicloud-k8s/tree/honolulu/kud +.. _KUD Interface Permission: https://jira.onap.org/browse/MULTICLOUD-1310 +.. _Frankfurt CBA Definition: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba/Definitions/vFW_CNF_CDS.json?h=frankfurt +.. _Frankfurt CBA Script: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba/Scripts/kotlin/KotlinK8sProfileUpload.kt?h=frankfurt +.. _SO-3403: https://jira.onap.org/browse/SO-3403 +.. _SO-3404: https://jira.onap.org/browse/SO-3404 +.. _REQ-182: https://jira.onap.org/browse/REQ-182 +.. _REQ-341: https://jira.onap.org/browse/REQ-341 +.. _REQ-458: https://jira.onap.org/browse/REQ-458 +.. _REQ-627: https://jira.onap.org/browse/REQ-627 +.. _REQ-890: https://jira.onap.org/browse/REQ-890 +.. _Python SDK: https://docs.onap.org/projects/onap-integration/en/latest/integration-tooling.html#python-onap-sdk .. _KUD Jenkins ci/cd verification: https://jenkins.onap.org/job/multicloud-k8s-master-kud-deployment-verify-shell/ -.. _SO Cloud Region Selection: https://git.onap.org/so/tree/adapters/mso-openstack-adapters/src/main/java/org/onap/so/adapters/vnf/MsoVnfPluginAdapterImpl.java?h=elalto#n1149 -.. _SO Monitoring: https://wiki.onap.org/display/DW/SO+Monitoring+User+Guide -.. _Jira Epic: https://jira.onap.org/browse/INT-1184 -.. _Data Dictionary: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba-dd.json?h=frankfurt -.. _Helm Healer: https://git.onap.org/oom/offline-installer/tree/tools/helm-healer.sh -.. _CDS UAT Testing: https://wiki.onap.org/display/DW/Modeling+Concepts -.. _postman.zip: files/vFW_CNF_CDS/postman.zip -.. _logs.zip: files/vFW_CNF_CDS/logs.zip -.. _SDC-2776: https://jira.onap.org/browse/SDC-2776 -.. _MULTICLOUD-941: https://jira.onap.org/browse/MULTICLOUD-941 -.. _CCSDK-2155: https://jira.onap.org/browse/CCSDK-2155 -.. _infra_workload: https://docs.onap.org/en/latest/submodules/multicloud/framework.git/docs/specs/multicloud_infra_workload.html -.. _SDNC-1116: https://jira.onap.org/browse/SDNC-1116 -.. _SO-2727: https://jira.onap.org/browse/SO-2727 -.. _SDNC-1109: https://jira.onap.org/browse/SDNC-1109 -.. _SDC-2776: https://jira.onap.org/browse/SDC-2776 -.. _INT-1255: https://jira.onap.org/browse/INT-1255 -.. _SDNC-1130: https://jira.onap.org/browse/SDNC-1130 +.. _K8s cloud site config: https://docs.onap.org/en/latest/guides/onap-operator/cloud_site/k8s/index.html +.. _SO Monitoring: https://docs.onap.org/projects/onap-so/en/latest/developer_info/Working_with_so_monitoring.html +.. _Data Dictionary: https://git.onap.org/demo/tree/heat/vFW_CNF_CDS/templates/cba-dd.json?h=guilin +.. _Helm Healer: https://git.onap.org/oom/offline-installer/tree/tools/helm-healer.sh?h=frankfurt +.. _infra_workload: https://docs.onap.org/projects/onap-multicloud-framework/en/latest/specs/multicloud_infra_workload.html?highlight=multicloud +.. _K8s Client Compatibility: https://github.com/kubernetes/client-go +.. _CNF Health Check: https://docs.onap.org/projects/onap-so/en/latest/api/apis/serviceInstances-api.html#healthcheck +.. _K8s Resource in AAI: https://jira.onap.org/browse/ONAPMODEL-37 +.. _AAI v24 schema: https://nexus.onap.org/service/local/repositories/releases/archive/org/onap/aai/schema-service/aai-schema/1.9.2/aai-schema-1.9.2.jar/!/onap/aai_swagger_html/aai_swagger_v24.html diff --git a/docs/docs_vfw.rst b/docs/docs_vfw.rst index ec46e5c64..1fdb2aaa7 100644 --- a/docs/docs_vfw.rst +++ b/docs/docs_vfw.rst @@ -1,5 +1,7 @@ .. _docs_vfw: +:orphan: + vFirewall Use Case ------------------ @@ -109,9 +111,8 @@ 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`__. - -__ https://wiki.onap.org/display/DW/Running+the+ONAP+Demos +please look at the videos and the material available in +`Running the ONAP Demos wiki page <https://wiki.onap.org/display/DW/Running+the+ONAP+Demos>`_ Although videos are still valid, users are encouraged to use the Heat templates linked at the top of this page rather than the old Heat templates in that wiki page. diff --git a/docs/docs_vfwHPA.rst b/docs/docs_vfwHPA.rst index 015b725e6..147d80d2a 100644 --- a/docs/docs_vfwHPA.rst +++ b/docs/docs_vfwHPA.rst @@ -4,6 +4,8 @@ .. _docs_vfw_hpa: +:orphan: + vFW/vDNS with HPA Tutorial: Setting Up and Configuration -------------------------------------------------------- @@ -27,11 +29,8 @@ This tutorial covers enhancements 1 to 5 in Background of https://wiki.onap.org/ Setting Up and Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Some fixes for HPA support were made subsequent to the release of the Casablanca images. Several updated docker images need to be used to utilize the fixes. The details of the docker images that need to be used and the issues that are fixed are described at this link https://wiki.onap.org/display/DW/Docker+image+updates+for+HPA+vFW+testing - -Instructions for updating the manifest of ONAP docker images can be found here: https://onap.readthedocs.io/en/casablanca/submodules/integration.git/docs/#deploying-an-updated-docker-manifest -Install OOM ONAP using the deploy script in the integration repo. Instructions for this can be found in this link https://wiki.onap.org/display/DW/OOM+Component. When the installation is complete (all the pods are either in running or completed state) Do the following; +Install OOM ONAP using the deploy script in the integration repo. Instructions for this can be found in this link https://docs.onap.org/projects/onap-oom/en/latest/sections/guides/deployment_guides/oom_deployment.html. When the installation is complete (all the pods are either in running or completed state) Do the following; 1. Check that all the required components were deployed; @@ -219,7 +218,7 @@ If an update is needed, the update can be done via rest using curl or postman }' -9. Register new cloud regions. This can be done using instructions (Step 1 to Step 3) on this `page <https://onap.readthedocs.io/en/latest/submodules/multicloud/framework.git/docs/multicloud-plugin-windriver/UserGuide-MultiCloud-WindRiver-TitaniumCloud.html#tutorial-onboard-instance-of-wind-river-titanium-cloud>`_. The already existing CloudOwner and cloud complex can be used. If step 3 does not work using the k8s ip and external port. It can be done using the internal ip address and port. Exec into any pod and run the command from the pod. +9. Register new cloud regions. This can be done using instructions (Step 1 to Step 3) on this `page <https://docs.onap.org/projects/onap-multicloud-framework/en/latest/multicloud-plugin-windriver/UserGuide-MultiCloud-WindRiver-TitaniumCloud.html?highlight=multicloud>`_. The already existing CloudOwner and cloud complex can be used. If step 3 does not work using the k8s ip and external port. It can be done using the internal ip address and port. Exec into any pod and run the command from the pod. - Get msb-iag internal ip address and port diff --git a/docs/docs_vfw_edgex_k8s.rst b/docs/docs_vfw_edgex_k8s.rst index a25b349a2..256d65948 100644 --- a/docs/docs_vfw_edgex_k8s.rst +++ b/docs/docs_vfw_edgex_k8s.rst @@ -4,6 +4,8 @@ .. _docs_vfw_edgex_multicloud_k8s: +:orphan: + vFW/Edgex with Multicloud Kubernetes Plugin: Setting Up and Configuration ------------------------------------------------------------------------- @@ -201,8 +203,8 @@ It is an example of the minimal HEAT template. 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>`__. +For onboarding instructions please refer to steps 4-9 from +`vFWCL instantiation, testing and debuging wiki page <https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging>`_. Steps for installing KUD Cloud ------------------------------ @@ -210,9 +212,8 @@ Steps for installing KUD Cloud Follow the link to install KUD Kubernetes Deployment. KUD contains all the packages required for running vfw use case. -Kubernetes Baremetal deployment instructions can be found here_ - -.. _here: https://wiki.onap.org/display/DW/Kubernetes+Baremetal+deployment+setup+instructions/ +Kubernetes Baremetal deployment instructions can be found in +`Kubernetes Baremetal deployment setup instructions wiki page <https://wiki.onap.org/display/DW/Kubernetes+Baremetal+deployment+setup+instructions>`_ REGISTER KUD CLOUD REGION with K8s-Plugin ----------------------------------------- @@ -272,15 +273,15 @@ registration) pointing to a real OpenStack tenant (e.g. the OOF tenant in 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>`__, +then, similarly to #10 in the +`vFW HPA casablanca official documentation <https://docs.onap.org/projects/onap-integration/en/latest/docs_vfwHPA.html>`_, 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://onap.readthedocs.io/en/latest/submodules/multicloud/framework.git/docs/multicloud-plugin-windriver/UserGuide-MultiCloud-WindRiver-TitaniumCloud.html#tutorial-onboard-instance-of-wind-river-titanium-cloud>`__. +`Multicloud Windriver Plugin documentation <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 +648,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_vipsec.rst b/docs/docs_vipsec.rst index 755d4c085..db9e894ad 100644 --- a/docs/docs_vipsec.rst +++ b/docs/docs_vipsec.rst @@ -4,6 +4,8 @@ .. _docs_vipsec_hpa: +:orphan: + vIPsec with HPA Tutorial: Setting Up and Configuration -------------------------------------------------------- @@ -22,13 +24,11 @@ The deploy steps look just alike the one for vFW with HPA use case. It is also u Setting Up and Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Instructions for updating the manifest of ONAP docker images can be found here: https://onap.readthedocs.io/en/casablanca/submodules/integration.git/docs/#deploying-an-updated-docker-manifest - Install OOM ONAP using the deploy script in the integration repo. Instructions for this can be found in this link https://wiki.onap.org/display/DW/OOM+Component. When the installation is complete (all the pods are either in running or completed state) Do the following; 1. Check that all the required components were deployed; - + ``oom-rancher# helm list`` 2. Check the state of the pods; @@ -37,14 +37,14 @@ Install OOM ONAP using the deploy script in the integration repo. Instructions f 3. Run robot health check - ``oom-rancher# cd oom/kubernetes/robot`` + ``oom-rancher# cd oom/kubernetes/robot`` ``oom-rancher# ./ete-k8s.sh onap health`` Ensure all the required components pass the health tests 4. Modify the SO bpmn configmap to change the SO vnf adapter endpoint to v2 - - ``oom-rancher# kubectl -n onap edit configmap dev-so-so-bpmn-infra-app-configmap`` + + ``oom-rancher# kubectl -n onap edit configmap dev-so-so-bpmn-infra-app-configmap`` ``- vnf:`` @@ -73,7 +73,7 @@ Install OOM ONAP using the deploy script in the integration repo. Instructions f ``oom-rancher# ./demo-k8s.sh onap init`` -7. Create HPA flavors in cloud regions to be registered with ONAP. All HPA flavor names must start with onap. During our tests, 3 cloud regions were registered and we created flavors in each cloud. The flavors match the flavors described in the test plan `here <https://wiki.onap.org/pages/viewpage.action?pageId=41421112>`_. +7. Create HPA flavors in cloud regions to be registered with ONAP. All HPA flavor names must start with onap. During our tests, 3 cloud regions were registered and we created flavors in each cloud. The flavors match the flavors described in the test plan `here <https://wiki.onap.org/pages/viewpage.action?pageId=41421112>`_. - **Cloud Region One** @@ -81,7 +81,7 @@ Install OOM ONAP using the deploy script in the integration repo. Instructions f ``#nova flavor-create onap.hpa.flavor11 111 8 20 2`` ``#nova flavor-key onap.hpa.flavor11 set hw:mem_page_size=2048`` - + **Flavor12** ``#nova flavor-create onap.hpa.flavor12 112 12 20 2`` @@ -90,9 +90,9 @@ Install OOM ONAP using the deploy script in the integration repo. Instructions f ``#openstack aggregate create --property aggregate_instance_extra_specs:sriov_nic=sriov-nic-intel-8086-154C-shared-1:3 aggr121`` ``#openstack flavor set onap.hpa.flavor12 --property aggregate_instance_extra_specs:sriov_nic=sriov-nic-intel-8086-154C-shared-1:3`` - + **Flavor13** - ``#nova flavor-create onap.hpa.flavor13 113 12 20 2`` + ``#nova flavor-create onap.hpa.flavor13 113 12 20 2`` ``#nova flavor-key onap.hpa.flavor13 set hw:mem_page_size=2048`` @@ -110,7 +110,7 @@ Install OOM ONAP using the deploy script in the integration repo. Instructions f ``#nova flavor-key onap.hpa.flavor21 set hw:cpu_policy=dedicated`` ``#nova flavor-key onap.hpa.flavor21 set hw:cpu_thread_policy=isolate`` - + **Flavor22** ``#nova flavor-create onap.hpa.flavor22 222 12 20 2`` @@ -119,9 +119,9 @@ Install OOM ONAP using the deploy script in the integration repo. Instructions f ``#openstack aggregate create --property aggregate_instance_extra_specs:sriov_nic=sriov-nic-intel-8086-154C-shared-1:2 aggr221`` ``#openstack flavor set onap.hpa.flavor22 --property aggregate_instance_extra_specs:sriov_nic=sriov-nic-intel-8086-154C-shared-1:2`` - + **Flavor23** - ``#nova flavor-create onap.hpa.flavor23 223 12 20 2`` + ``#nova flavor-create onap.hpa.flavor23 223 12 20 2`` ``#nova flavor-key onap.hpa.flavor23 set hw:mem_page_size=2048`` @@ -139,20 +139,20 @@ Install OOM ONAP using the deploy script in the integration repo. Instructions f ``#nova flavor-key onap.hpa.flavor31 set hw:cpu_policy=dedicated`` ``#nova flavor-key onap.hpa.flavor31 set hw:cpu_thread_policy=isolate`` - + **Flavor32** ``#nova flavor-create onap.hpa.flavor32 332 8192 20 2`` ``#nova flavor-key onap.hpa.flavor32 set hw:mem_page_size=1048576`` - + **Flavor33** - ``#nova flavor-create onap.hpa.flavor33 333 12 20 2`` + ``#nova flavor-create onap.hpa.flavor33 333 12 20 2`` ``#nova flavor-key onap.hpa.flavor33 set hw:mem_page_size=2048`` ``#openstack aggregate create --property aggregate_instance_extra_specs:sriov_nic=sriov-nic-intel-8086-154C-shared-1:1 aggr331`` - ``#openstack flavor set onap.hpa.flavor33 --property aggregate_instance_extra_specs:sriov_nic=sriov-nic-intel-8086-154C-shared-1:1`` + ``#openstack flavor set onap.hpa.flavor33 --property aggregate_instance_extra_specs:sriov_nic=sriov-nic-intel-8086-154C-shared-1:1`` 8. Check that the cloud complex has the right values and update if it does not. Required values are; @@ -205,7 +205,7 @@ If an update is needed, the update can be done via rest using curl or postman }' -9. Register new cloud regions. This can be done using instructions (Step 1 to Step 3) on this `page <https://onap.readthedocs.io/en/latest/submodules/multicloud/framework.git/docs/multicloud-plugin-windriver/UserGuide-MultiCloud-WindRiver-TitaniumCloud.html#tutorial-onboard-instance-of-wind-river-titanium-cloud>`_. The already existing CloudOwner and cloud complex can be used. If step 3 does not work using the k8s ip and external port. It can be done using the internal ip address and port. Exec into any pod and run the command from the pod. +9. Register new cloud regions. This can be done using instructions (Step 1 to Step 3) on this `page <https://docs.onap.org/projects/onap-multicloud-framework/en/latest/multicloud-plugin-windriver/UserGuide-MultiCloud-WindRiver-TitaniumCloud.html?highlight=multicloud>`_. The already existing CloudOwner and cloud complex can be used. If step 3 does not work using the k8s ip and external port. It can be done using the internal ip address and port. Exec into any pod and run the command from the pod. - Get msb-iag internal ip address and port @@ -215,7 +215,7 @@ If an update is needed, the update can be done via rest using curl or postman ``oom-rancher# kubectl exec dev-oof-oof-6c848594c5-5khps -it -- bash`` -10. Put required subscription list into tenant for all the newly added cloud regions. An easy way to do this is to do a get on the default cloud region, copy the tenant information with the subscription. Then paste it in your put command and modify the region id, tenant-id, tenant-name and resource-version. +10. Put required subscription list into tenant for all the newly added cloud regions. An easy way to do this is to do a get on the default cloud region, copy the tenant information with the subscription. Then paste it in your put command and modify the region id, tenant-id, tenant-name and resource-version. **GET COMMAND** @@ -360,14 +360,14 @@ If an update is needed, the update can be done via rest using curl or postman } }' - + 11. Onboard the vFW HPA template. The templates can be gotten from the `demo <https://github.com/onap/demo>`_ repo. The heat and env files used are located in demo/heat/vFW_HPA/vFW/. Create a zip file using the files. For onboarding instructions see steps 4 to 9 of `vFWCL instantiation, testing and debugging <https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging>`_. Note that in step 5, only one VSP is created. For the VSP the option to submit for testing in step 5cii was not shown. So you can check in and certify the VSP and proceed to step 6. 12. Get the parameters (model info, model invarant id...etc) required to create a service instance via rest. This can be done by creating a service instance via VID as in step 10 of `vFWCL instantiation, testing and debugging <https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging>`_. After creating the service instance, exec into the SO bpmn pod and look into the /app/logs/bpmn/debug.log file. Search for the service instance and look for its request details. Then populate the parameters required to create a service instance via rest in step 13 below. 13. Create a service instance rest request but do not create service instance yet. Specify OOF as the homing solution and multicloud as the orchestrator. Be sure to use a service instance name that does not exist and populate the parameters with values gotten from step 12. -:: +:: curl -k -X POST \ http://{{k8s}}:30277/onap/so/infra/serviceInstances/v6 \ @@ -448,14 +448,14 @@ To Update a policy, use the following curl command. Modify the policy as require "onapName": "SampleDemo", "policyScope": "OSDF_DUBLIN" }' 'https://pdp:8081/pdp/api/updatePolicy' - + To delete a policy, use two commands below to delete from PDP and PAP **DELETE POLICY INSIDE PDP** :: - + curl -k -v -H 'Content-Type: application/json' \ -H 'Accept: application/json' \ -H 'ClientAuth: cHl0aG9uOnRlc3Q=' \ @@ -468,7 +468,7 @@ To delete a policy, use two commands below to delete from PDP and PAP **DELETE POLICY INSIDE PAP** :: - + curl -k -v -H 'Content-Type: application/json' \ -H 'Accept: application/json' \ -H 'ClientAuth: cHl0aG9uOnRlc3Q=' \ @@ -495,7 +495,7 @@ Create Policy -Push Policy +Push Policy :: @@ -506,7 +506,7 @@ Push Policy }' 'https://pdp:8081/pdp/api/pushPolicy' - + 17. Create Service Instance using step 13 above 18. Check bpmn logs to ensure that OOF sent homing response and flavor directives. @@ -538,7 +538,7 @@ Push Policy "vnf-vms": [] }, - + "vnf-parameters": [ { "vnf-parameter-name":"vf_module_id", @@ -787,13 +787,13 @@ Push Policy "service-type": "8c071bd1-c361-4157-8282-3fef7689d32e", "vnf-name": "ipsec-test", "vnf-type": "Ipsec..base_vipsec..module-0" - + } } }} - -Change parameters based on your environment. + +Change parameters based on your environment. **Note** @@ -804,5 +804,5 @@ Change parameters based on your environment. "service-type": "8c071bd1-c361-4157-8282-3fef7689d32e", <-- same as Service Instance ID "vnf-name": "ipsec-test", <-- name to be given to the vf module "vnf-type": "Ipsec..base_vipsec..module-0" <-- can be found on the VID - VF Module dialog screen - Model Name - + 21. Create vf module (11g of `vFWCL instantiation, testing and debugging <https://wiki.onap.org/display/DW/vFWCL+instantiation%2C+testing%2C+and+debuging>`_). If everything worked properly, you should see the stack created in your VIM(WR titanium cloud openstack in this case). diff --git a/docs/docs_vlb.rst b/docs/docs_vlb.rst index ded308f05..5a9f6a2fb 100644 --- a/docs/docs_vlb.rst +++ b/docs/docs_vlb.rst @@ -1,5 +1,7 @@ .. _docs_vlb: +:orphan: + vLoadBalancer Use Case ---------------------- @@ -15,7 +17,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 +25,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 +36,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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -69,10 +71,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" - 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; +- {"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: @@ -83,18 +84,20 @@ For example, if you want to enable 3 streams, the curl command will be: When the VNF starts, the packet generator is automatically configured to run 5 streams. - 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`__. - -__ https://wiki.onap.org/display/DW/Running+the+ONAP+Demos +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 +`Running the ONAP Demos wiki page <https://wiki.onap.org/display/DW/Running+the+ONAP+Demos>`_ -Although videos are still valid, users are encouraged to use the Heat templates linked at the top of this page rather than the old Heat templates in that wiki page. +Although videos are still valid, users are encouraged to use the Heat templates +linked at the top of this page rather than the old Heat templates in that wiki page. Known issues and resolution ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -1) The packet generator may become unresponsive and stop generating traffic. To solve the problem, reboot the packet generator. +1) The packet generator may become unresponsive and stop generating traffic. + To solve the problem, reboot the packet generator. 2) The base and scaling VF module names need to follow a specific naming convention: @@ -102,4 +105,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/files/CI/ONAP_CI_8.png b/docs/files/CI/ONAP_CI_8.png Binary files differindex 2182c7123..3263e93f8 100644..100755 --- a/docs/files/CI/ONAP_CI_8.png +++ b/docs/files/CI/ONAP_CI_8.png diff --git a/docs/files/csv/release-demo-features.csv b/docs/files/csv/release-demo-features.csv new file mode 100644 index 000000000..22bc99eaa --- /dev/null +++ b/docs/files/csv/release-demo-features.csv @@ -0,0 +1,5 @@ +Issue-ID;Description +INT-2094;[APACHE] Add Apache CNF use case files +INT-2069;Make Network Slicing usecase more user friendly +INT-1960;[vFW CNF CDS] Fix issue with multiple tenants creation for k8s region +INT-1960;[vFW CNF CDS] vf_module and vnf name generation improvment in CBA diff --git a/docs/files/csv/release-integration-features.csv b/docs/files/csv/release-integration-features.csv new file mode 100644 index 000000000..ed06a4284 --- /dev/null +++ b/docs/files/csv/release-integration-features.csv @@ -0,0 +1,5 @@ +Issue-ID;Description +INT-2070;Automate 5G Slicing use case in CI - Manual configuration step 7 - AAI Configuration +INT-2164;Update Apache CNF Demo +INT-2126;Data provider - add relationships into cloud region and tenant +INT-2135;Add CPS resources into data-provider diff --git a/docs/files/csv/release-integration-ref.csv b/docs/files/csv/release-integration-ref.csv new file mode 100644 index 000000000..b9f3535ef --- /dev/null +++ b/docs/files/csv/release-integration-ref.csv @@ -0,0 +1,39 @@ +Repository;Revision +demo;5dcd47bfc76ab8257fcc3b8927b78295a4376c8b +integration;cdacb811f7acc2eb0a6e5662d8d225a967160f2c +integration/csit;08bc9551a07da29c478ca2f6487aafa651ea95dd +integration/data-provider;3f1416193789e00f6b09029c7e841d98803e5749 +integration/docker/onap-java11;1a5e22c812aa988fbfc27a668c1d2541db971080 +integration/docker/onap-python;e2de6cdd2d5f2e4a8067c40d1af0392b02426d61 +integration/ietf-actn-tools;3a8b2c604c13584fbc807ac21058288c424893b3 +integration/onap-component-simulators;748da401868fbf35744e292ee132be614b489623 +integration/pipelines/chained-ci;0399d9842c2a5670e4ee21d45343d2ac168eee2d +integration/pipelines/oom-automatic-installation;4934d86bfe15a6132331f802afb4b3a062cbaf8c +integration/pipelines/xtesting-onap;276fb7948607bd6b3fc09693619f021763b5ec6e +integration/python-onapsdk;25cafb994c9ba3b874cd973a1e1d440fb0b98bf0 +integration/seccom;0131d962bdfcf97794ac49a2f45f5eb974249288 +integration/simulators/5G-core-nf-simulator;1eaabdb8299e49dc7e81c205edce8ce46e64a511 +integration/simulators/A1-policy-enforcement-simulator;63501fbea1b8a6dc859099c3465b1758e19e0956 +integration/simulators/core-nssmf-simulator;5ce930d4a9e8137b1fbac98a58ebe2cfd3e6a77e +integration/simulators/nf-simulator;b4e937c4c92ef68fd1ab640ce9e30a531112b371 +integration/simulators/nf-simulator/avcn-manager;13fab3acdc7a22ca7000125112c84a2e942ea307 +integration/simulators/nf-simulator/netconf-server;8d0a5c8e95ef58e391eee31c1562dcb541c4c369 +integration/simulators/nf-simulator/pm-https-server;1f0bcaac6410f2a5497aad7c6ed5e46610a4a8a7 +integration/simulators/nf-simulator/ves-client;94891f32b3e2c4be8240b4df88830f97f2255e0b +integration/simulators/pnf-simulator;f00c718bc3978d5b7ed55a5cda1c2a1443919af9 +integration/simulators/ran-app;746cc0a4aa1ada72d98ed161322fb2bd1e359637 +integration/simulators/ran-nssmf-simulator;1528d0a38026e3e183de2d4dcf7bbfcfec633eda +integration/simulators/ran-simulator;41bbe166748510b4c5be7606ff27ee7ee64cb001 +integration/usecases/A1-policy-enforcement;0a885a2b3595988922b8e7af3e76bef4913de8bd +integration/usecases/A1-policy-enforcement-r-apps;e3f79f43ba8e51fda97a5d67cd5c01b04e54c9e1 +integration/xtesting;c90366fa6ec58cd063addcf50c6948ea859f5fc9 +oparent;371de4b87ccf46f1292d68468fcfd41303ab394c +testsuite;d7fe3776469399384a340b9a38e2c0de8771e6c1 +testsuite/cds;a5eb7d86926fac92965c35de1cae9114dc471a35 +testsuite/cds-mock-odl;b7f29dc3f03ec40369941af6e525d40c822d1ced +testsuite/cds-mock-server;7db71adaf139e54f2186cfd19d468f5a1123835d +testsuite/cds-mock-ssh;a43ce8950dcc36363c406b1cc4043dc7d623c9f4 +testsuite/oom;9e5fee150e86c868c0ef40f2a34494be36bd41fc +testsuite/python-testing-utils;f9d29ad319d54cdabe63b52c20c9acd9d475347b +testsuite/pythonsdk-tests;a9dddc1095dad400626871f3f1dc5df96d05e035 +testsuite/robot-utils;7e7fbedd13aa9c33433601c8d276f0d43fcd6c78 diff --git a/docs/files/csv/release-oparent-features.csv b/docs/files/csv/release-oparent-features.csv new file mode 100644 index 000000000..b4a48add1 --- /dev/null +++ b/docs/files/csv/release-oparent-features.csv @@ -0,0 +1,4 @@ +Issue-ID;Description + +USECASEUI-709;Upgrade dependency versions in oparent +USECASEUI-709;Update Logback to Version 1.2.10 diff --git a/docs/files/csv/release-pythonsdk-features.csv b/docs/files/csv/release-pythonsdk-features.csv new file mode 100644 index 000000000..6d96dd7b7 --- /dev/null +++ b/docs/files/csv/release-pythonsdk-features.csv @@ -0,0 +1,2 @@ +Issue-ID;Description +INT-2119;Use 10.0.0 version of SDK in tests
\ No newline at end of file diff --git a/docs/files/csv/release-testsuite-features.csv b/docs/files/csv/release-testsuite-features.csv new file mode 100644 index 000000000..2b05ce227 --- /dev/null +++ b/docs/files/csv/release-testsuite-features.csv @@ -0,0 +1,2 @@ +Issue-ID;Description +INT-2160;[ROBOT] Fix the DCAEMOD testcase for ServiceMes diff --git a/docs/files/csv/repo-archived.csv b/docs/files/csv/repo-archived.csv new file mode 100644 index 000000000..4eedae852 --- /dev/null +++ b/docs/files/csv/repo-archived.csv @@ -0,0 +1,10 @@ +Repository;Description;Link +integration/benchmark;Benchmark project;`link <https://git.onap.org/integration/benchmark>`__ +integration/devtool;Devtool project;`link <https://git.onap.org/integration/devtool>`__ +integration/simulators/dc-simulator;Data Center simulator;`link <https://git.onap.org/integration/simulators/dc-simulator>`__ +integration/simulators/masspnf-simulator;Mass PNF Simulator;`link <https://git.onap.org/integration/simulators/masspnf-simulator>`__ +integration/terraform;Terraform based alternative infrastructure installation;`link <https://git.onap.org/integration/terraform>`__ +integration/terragrunt;Compagnon repository of terraform;`link <https://git.onap.org/integration/terragrunt>`__ +integration/usecases/bbs;BBS use case introduced in Dublin and extracted from global repository in frankfurt;`link <https://git.onap.org/integration/usecases/bbs>`__ +integration/usecases/mdons;MDONS use case introduced in Frankfurt;`link <https://git.onap.org/integration/usecases/mdons>`__ +testsuite/heatbridge;python utils to manage the heatbridge function to enrich cloud information to AAI (deprecated);`link <https://git.onap.org/testsuite/heatbridge>`__
\ No newline at end of file diff --git a/docs/files/csv/repo-demo.csv b/docs/files/csv/repo-demo.csv new file mode 100644 index 000000000..2a1432693 --- /dev/null +++ b/docs/files/csv/repo-demo.csv @@ -0,0 +1,2 @@ +Repository;Description;Link +demo;Historical repository to host use case artifacts (heat templates, json files,..);`link <https://git.onap.org/demo>`__ diff --git a/docs/files/csv/repo-integration-external.csv b/docs/files/csv/repo-integration-external.csv new file mode 100644 index 000000000..dc401c0a9 --- /dev/null +++ b/docs/files/csv/repo-integration-external.csv @@ -0,0 +1,2 @@ +Repository;Description;Link +integration-view;Repository integration hosting the itegration portal including the hosting of the web site;`link <https://gitlab.com/Orange-OpenSource/lfn/onap/integration-view>`__ diff --git a/docs/files/csv/repo-integration.csv b/docs/files/csv/repo-integration.csv new file mode 100644 index 000000000..b7d8a392a --- /dev/null +++ b/docs/files/csv/repo-integration.csv @@ -0,0 +1,13 @@ +Repository;Description;Link +integration;Historical main repository including documentation, simulators (e.g. mass PNF simulator), non robot tests (e.g. security tests, vCPE Tosca,..), ...;`link <https://git.onap.org/integration>`__ +integration/csit;Repository hosting some tooling to start component functional tests in Jenkins (To be deprecated in Guilin as such tests must be reinsourced by the projects);`link <https://git.onap.org/integration/csit>`__ +integration/data-provider;Project that provides a tool to automate common ONAP resource creation;`link <https://git.onap.org/integration/data-provider>`__ +integration/docker/onap-java11;Java11 baseline image conformed to SECCOM recommendations;`link <https://git.onap.org/integration/docker/onap-java11>`__ +integration/docker/onap-python;Python baseline image conformed to SECCOM recommendations;`link <https://git.onap.org/integration/docker/onap-python>`__ +integration/ietf-actn-tools;IETF ACTN tools introduced in Honolulu);`link <https://git.onap.org/integration/ietf-actn-tools>`__ +integration/onap-component-simulators;ONAP component simulators used for tests;`link <https://git.onap.org/integration/onap-component-simulators/>`__ +integration/python-onapsdk;ONAP Python SDK repository;`link <https://git.onap.org/integration/python-onapsdk/>`__ +integration/seccom;Repory hosting seccom recommended versions and security test waivers;`link <https://git.onap.org/integration/seccom>`__ +integration/usecases/A1-policy-enforcement;A1 policy enforcement introduced in Honolulu;`link <https://git.onap.org/integration/usecases/A1-policy-enforcement>`__ +integration/usecases/A1-policy-enforcement-r-apps;A1 policy enforcement (analyticis part) introduced in Honolulu;`link <https://git.onap.org/integration/usecases/A1-policy-enforcement-r-apps>`__ +integration/xtesting;Repository in charge to build th xtesting dockers used in CI/CD chains;`link <https://git.onap.org/integration/xtesting>`__ diff --git a/docs/files/csv/repo-oparent.csv b/docs/files/csv/repo-oparent.csv new file mode 100644 index 000000000..30cbdc78a --- /dev/null +++ b/docs/files/csv/repo-oparent.csv @@ -0,0 +1,3 @@ +Repository;Description;Link +oparent;Java dependencies for JAVA projects;`link <https://git.onap.org/oparent>`__ +oparent/cia;Dockerfile optimization and best practices;`link <https://git.onap.org/oparent/cia>`__ diff --git a/docs/files/csv/repo-pipelines.csv b/docs/files/csv/repo-pipelines.csv new file mode 100644 index 000000000..27e43e82c --- /dev/null +++ b/docs/files/csv/repo-pipelines.csv @@ -0,0 +1,4 @@ +Repository;Description;Link +integration/pipelines/chained-ci;Main pipelines project which holds configuration;`link <https://git.onap.org/integration/pipelines/chained-ci/>`__ +integration/pipelines/oom-automatic-installation;Definition of pipelines to instantiate ONAP;`link <https://git.onap.org/integration/pipelines/oom-automatic-installation/>`__ +integration/pipelines/xtesting-onap;Definition of pipelines to execute tests;`link <https://git.onap.org/integration/pipelines/xtesting-onap/>`__
\ No newline at end of file diff --git a/docs/files/csv/repo-simulators.csv b/docs/files/csv/repo-simulators.csv new file mode 100644 index 000000000..91f75eb66 --- /dev/null +++ b/docs/files/csv/repo-simulators.csv @@ -0,0 +1,13 @@ +Repository;Description;Link +integration/simulators/5G-core-nf-simulator;5G core nf simulator;`link <https://git.onap.org/integration/simulators/5G-core-nf-simulator>`__ +integration/simulators/A1-policy-enforcement-simulator;A1 Policy Enforcement Simulator;`link <https://git.onap.org/integration/simulators/A1-policy-enforcement-simulator>`__ +integration/simulators/core-nssmf-simulator;Core NSSMF Simulator;`link <https://git.onap.org/integration/simulators/core-nssmf-simulator>`__ +integration/simulators/nf-simulator;NF simulator;`link <https://git.onap.org/integration/simulators/nf-simulator>`__ +integration/simulators/nf-simulator/avcn-manager;NF simulator avcn manager;`link <https://git.onap.org/integration/simulators/nf-simulator/avcn-manager>`__ +integration/simulators/nf-simulator/netconf-server;NF simulator netconf server;`link <https://git.onap.org/integration/simulators/nf-simulator/netconf-server>`__ +integration/simulators/nf-simulator/pm-https-server;NF simulator pm https server;`link <https://git.onap.org/integration/simulators/nf-simulator/pm-https-server>`__ +integration/simulators/nf-simulator/ves-client;NF simulator ves client;`link <https://git.onap.org/integration/simulators/nf-simulator/ves-client>`__ +integration/simulators/pnf-simulator;PNF Simulator;`link <https://git.onap.org/integration/simulators/pnf-simulator>`__ +integration/simulators/ran-app;RAN App;`link <https://git.onap.org/integration/simulators/ran-app/>`__ +integration/simulators/ran-nssmf-simulator;RAN NSSMF simulator;`link <https://git.onap.org/integration/simulators/ran-nssmf-simulator>`__ +integration/simulators/ran-simulator;RAN simulator;`link <https://git.onap.org/integration/simulators/ran-simulator>`__ diff --git a/docs/files/csv/repo-testsuite.csv b/docs/files/csv/repo-testsuite.csv new file mode 100644 index 000000000..79fc01860 --- /dev/null +++ b/docs/files/csv/repo-testsuite.csv @@ -0,0 +1,10 @@ +Repository;Description;Link +testsuite;repository hosting the robot test suites;`link <https://git.onap.org/testsuite>`__ +testsuite/cds;Repository hosting (standalone) CDS test suites shared by Bell Canada team, not yet integrated in CI/CD;`link <https://git.onap.org/testsuite/cds>`__ +testsuite/cds-mock-odl;needed for cds regression tests;`link <https://git.onap.org/testsuite/cds-mock-odl>`__ +testsuite/cds-mock-server;needed for cds regression tests;`link <https://git.onap.org/testsuite/cds-mock-server>`__ +testsuite/cds-mock-ssh;needed for cds regression tests;`link <https://git.onap.org/testsuite/cds-mock-ssh>`__ +testsuite/oom;Helm chart for robot pod (to be deprecated in Honolulu and moved back to OOM);`link <https://git.onap.org/testsuite/oom>`__ +testsuite/python-testing-utils;Python and robot util libraries used for robot tests;`link <https://git.onap.org/testsuite/python-testing-utils>`__ +testsuite/pythonsdk-tests;Repository hosting the test scenarios leveraging python-onapsdk for end to end smoke tests;`link <https://git.onap.org/testsuite/pythonsdk-tests>`__ +testsuite/robot-utils;Repository aiming to provide a robot wrapper for python-onapsdk;`link <https://git.onap.org/testsuite/robot-utils>`__ diff --git a/docs/files/csv/s3p-instantiation.csv b/docs/files/csv/s3p-instantiation.csv new file mode 100644 index 000000000..d21f2ee5e --- /dev/null +++ b/docs/files/csv/s3p-instantiation.csv @@ -0,0 +1,6 @@ +Parameters;Jakarta;Istanbul;Honolulu +Number of tests;1190;1310;1410 +Global success rate;96%;97%;96% +Min duration;140s;193s;81s +Max duration;2075s;2128s;2000s +mean duration;603s;564s;530s
\ No newline at end of file diff --git a/docs/files/csv/s3p-sdc.csv b/docs/files/csv/s3p-sdc.csv new file mode 100644 index 000000000..cd9bb9e6c --- /dev/null +++ b/docs/files/csv/s3p-sdc.csv @@ -0,0 +1,6 @@ +Parameters;Jakarta;Istanbul;Honolulu +Number of tests;1000;1085;715 +Global success rate;92%;92%;93% +Min duration;119;111s;80s +Max duration;844;799s;1128s +mean duration;394s;366s;565s
\ No newline at end of file diff --git a/docs/files/csv/simulators.csv b/docs/files/csv/simulators.csv new file mode 100644 index 000000000..69e6b57f8 --- /dev/null +++ b/docs/files/csv/simulators.csv @@ -0,0 +1,6 @@ +Name;Description;Link;Contacts +NF Simulator;Evolution of the pnf simulator, the Network service simulator;:ref:`official doc <nf_simulator>`;K.Kuzmicki +A1 Policy Enforcement Simulator;Simulator that supports the A1-P OSC_2.1.0 interface and also provides internal API to manage the RAN elements (Cells, Ues) and allows to customize and send VES Events;`official readme <https://git.onap.org/integration/simulators/A1-policy-enforcement-simulator/tree/README.md>`__;Krystian Kędroń +Mass PNF Simulator;Mimic the PNF for benchmark purposes;`official readme <https://git.onap.org/integration/simulators/masspnf-simulator/tree/README.md>`__;Tamas Bakai +Ran simulator;RAN-SIM is a Radio Access Network Simulator, it is used to simulate the various functionalities of an eNodeB;`official readme <https://git.onap.org/integration/simulators/ran-simulator/tree/README.md>`__;Priyadharshini B +DC simulator;Data Center simulator;`official readme <https://git.onap.org/integration/simulators/dc-simulator/tree/README.md>`__;Xin Miao diff --git a/docs/files/csv/stability_basic_vm.csv b/docs/files/csv/stability_basic_vm.csv new file mode 100644 index 000000000..5ff8d0807 --- /dev/null +++ b/docs/files/csv/stability_basic_vm.csv @@ -0,0 +1,11 @@ +Basic_vm metric;Value +Number of PASS occurences;557 +Number of Raw FAIL Occurences;174 +Raw Success rate; 76% +Corrected success rate; 86% +Average duration of the test;549s (9m9s) +Min duration;188s (3m8s) +Max duration;2161 (36m1s) +Median duration;271s (4m34s) +% of Duration < 282s; 50% +% of duration > 660s; 29% diff --git a/docs/files/csv/stability_cluster_metric_cpu.csv b/docs/files/csv/stability_cluster_metric_cpu.csv new file mode 100644 index 000000000..e77d61691 --- /dev/null +++ b/docs/files/csv/stability_cluster_metric_cpu.csv @@ -0,0 +1,2 @@ +Namespace;CPU Utilisation (from requests);CPU utilisation (from limits);Memory Utilisation (from requests);Memory Utilisation (from limits) +onap;2.22%;0.816%;19%;7.4% diff --git a/docs/files/csv/stability_cluster_metric_memory.csv b/docs/files/csv/stability_cluster_metric_memory.csv new file mode 100644 index 000000000..40c6fa566 --- /dev/null +++ b/docs/files/csv/stability_cluster_metric_memory.csv @@ -0,0 +1,2 @@ +Namespace;Pods;Workloads;Memory Usage;Memory Requests;Memory Requests %;Memory Limits;Memory Limits % +onap;242;181;160.70 GiB;193.13 GiB;83.21%;493.09 GiB;32.59% diff --git a/docs/files/csv/stability_cluster_metric_network.csv b/docs/files/csv/stability_cluster_metric_network.csv new file mode 100644 index 000000000..46f02a7f7 --- /dev/null +++ b/docs/files/csv/stability_cluster_metric_network.csv @@ -0,0 +1,2 @@ +Namespace;Current Receive Bandwidth;Current Transmit Bandwidth;Rate of Received Packets;Rate of Transmitted Packets;Rate of Received Packets Dropped;Rate of Transmitted Packets Dropped +onap; 1.03 MBs; 1.07 MBs;5.08 kpps;5.02 kpps;0 pps;0 pps diff --git a/docs/files/csv/stability_top10_cpu.csv b/docs/files/csv/stability_top10_cpu.csv new file mode 100644 index 000000000..cdd93c1a9 --- /dev/null +++ b/docs/files/csv/stability_top10_cpu.csv @@ -0,0 +1,11 @@ +Pod;CPU Usage;CPU Requests;CPU Request %;CPU Limits;CPU Limits % +onap-robot;0.92;1;92%;4;23% +onap-cassandra-0;0.4;0.4;101%;1.6;25% +onap-cassandra-2;0.36;0.4;83%;1.6;22% +onap-ejbca;0.35;0.02;1771%;3;11% +onap-aws;0.35;6;6%;; +onap-cassandra-1;0.33;0.4;83%;1.6;21% +onap-oof-has-api;0.12;2;6%;8;1% +onap-music-cassandra-2;0.12;0.32;32%;1;12% +onap-dcae-cloudify-manager;0.11;2;6%;4;3% +onap-music-cassandra-1;0.09;0.32;29%;1;9% diff --git a/docs/files/csv/stability_top10_memory.csv b/docs/files/csv/stability_top10_memory.csv new file mode 100644 index 000000000..504afc2ac --- /dev/null +++ b/docs/files/csv/stability_top10_memory.csv @@ -0,0 +1,11 @@ +Pod;Memory Usage;Memory Requests;Memory Requests %;Memory Limits;Memory Limits % +onap-portal-cassandra;3.34 GiB;6.2 GiB;53.8%;7.5 GiB;45% +onap-cassandra-2;2.6 GiB;5 GiB;52%;8 GiB;32% +onap-cassandra-0;2.6 GiB;5 GiB;52%;8 GiB;32% +onap-cassandra-1;2.54 GiB;5 GiB;51%;8 GiB;32% +onap-appc;2.46 GiB;4 GiB;62%;8 GiB; 32% +onap-sdnc;2.43 GiB;4 GiB;61%;8 GiB; 30% +onap-policy-mariadb-0;2.4 GiB;1.96 GiB;122%;5.5 GiB;44% +onap-dcae-cloudify-manager;4.7 GiB;2 GiB;233%;4 GiB;115% +onap-awx;1.72 GiB;12 GiB;14%;; +onap-aaf-cass;1.45 GiB;2.5 GiB;58%;3.5 GiB;41.4% diff --git a/docs/files/csv/stability_top10_net.csv b/docs/files/csv/stability_top10_net.csv new file mode 100644 index 000000000..b86ba909f --- /dev/null +++ b/docs/files/csv/stability_top10_net.csv @@ -0,0 +1,11 @@ +Pod;Current Receive Bandwidth;Current Transmit Bandwidth;Rate of Received Packets;Rate of Transmitted Packets, Rate of Received Packets Dropped;Rate of Transmitted Packets Dropped +onap-oof-has-api;372 kB/s;670 B/s;9.21 p/s;5.4 p/s;0 p/s;0 p/s +onap-cassandra-2;231 kB/s;155 kB/s;90.35 p/s;69.84 p/s;0 p/s;0 p/s +onap-cassandra-1;228 kB/s;156 kB/s;87 p/s;82 p/s;0 p/s;0 p/s +onap-cassandra-0;144 kB/s;245 kB/s;63 p/s;75 p/s;0 p/s;0 p/s +onap-message-router-0;17 kB/s;18 kB/s;187 p/s;188 p/s;0 p/s;0 p/s +onap-portal-app;15 kB/s;4.7 kB/s;187 p/s;188 p/s;0 p/s;0 p/s +onap-consul;14 kB/s;3.9 kB/s;38 p/s;40 p/s;0 p/s;0 p/s +onap-message-router-kafka-010kB/s;10 kB/s;112 p/s;115 p/s;0 p/s;0 p/s +onap-dcaemodul-onboarding-apt_install;6.7 kB/s;6.1 kB/s;45 p/s;47 p/s;0 p/s;0 p/s +onap-message-router-kafka-2;6.3 kB/s;6.1 kB/s;70 p/s;72 p/s;0 p/s;0 p/s diff --git a/docs/files/csv/tests-healthcheck.csv b/docs/files/csv/tests-healthcheck.csv new file mode 100644 index 000000000..32ee6cfce --- /dev/null +++ b/docs/files/csv/tests-healthcheck.csv @@ -0,0 +1,11 @@ +Tests;Description;Code;Comments +core;Robot healthcheck tests of the core components (AA&I, DMAAP, Portal, SDC, SDNC, SO);`robot tests <https://git.onap.org/testsuite/tree/robot/testsuites/health-check.robot>`__;`robotframework <https://robotframework.org/>`__ +full;Robot healthcheck tests for all the components, **holmes healthcheck** have been reintroduced;`robot tests <https://git.onap.org/testsuite/tree/robot/testsuites/health-check.robot>`__;`robotframework <https://robotframework.org/>`__ +healthdist;Check the onboarding and distribution of the vFW;`robot tests <https://git.onap.org/testsuite/tree/robot/testsuites/health-check.robot>`__;`robotframework <https://robotframework.org/>`__ +postinstall;Check dmaap and AA&I Design model DB tests;`robot tests <https://git.onap.org/testsuite/tree/robot/testsuites/post-install-tests.robot>`__;`robotframework <https://robotframework.org/>`__ +ves-collector (new);Suite for checking handling events by VES Collector;`code <https://git.onap.org/testsuite/tree/robot/testsuites/ves.robot>`__;`robotframework <https://robotframework.org/>`__ +hv-ves;HV-VES 'Sunny Scenario' Robot Framework test - message is sent to the collector and Kafka topic is checked if the message has been published. Content is decoded and checked.;`code <https://git.onap.org/testsuite/tree/robot/testsuites/hvves-ci.robot>`__;`robotframework <https://robotframework.org/>`__ +basic_onboard;onboard a model, subset of most of the other basic_* tests, created to perform stability testing;`code <https://git.onap.org/testsuite/pythonsdk-tests/tree/src/onaptests/scenario/basic_onboard.py>`__;`onap_pythonsdk <https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk>`__, `pythonsdk-tests <https://git.onap.org/testsuite/pythonsdk-tests/tree/>`__ +cps-healthcheck;Call liveness and readiness probes of the CPS module;`robot tests <https://github.com/onap/cps/blob/master/csit/tests/actuator/actuator.robot>`__;`robotframework <https://robotframework.org/>`__ +**cps-temporal-healthcheck**;Call endpoints of CPS Temporal component;`robot tests <https://github.com/onap/cps-cps-temporal/blob/master/csit/tests/actuator/actuator.robot>`__;`robotframework <https://robotframework.org/>`__ +**cps-dmi-plugin-healthcheck**;Call endpoints of CPS DMI plugin component;`robot tests <https://github.com/onap/cps-ncmp-dmi-plugin/blob/master/csit/tests/actuator/actuator.robot>`__;`robotframework <https://robotframework.org/>`__
\ No newline at end of file diff --git a/docs/files/csv/tests-infrastructure-healthcheck.csv b/docs/files/csv/tests-infrastructure-healthcheck.csv new file mode 100644 index 000000000..a350f6bc8 --- /dev/null +++ b/docs/files/csv/tests-infrastructure-healthcheck.csv @@ -0,0 +1,4 @@ +Tests;Description;Code;Comments +onap-helm;Verify Helm chart status, the test has been updated to take into account Helm3;`python module <https://gitlab.com/Orange-OpenSource/lfn/tools/helm-onap-status>`__; +onap-k8s;Check common resources of the ONAP Kubernetes namespace ;`python module <https://gitlab.com/Orange-OpenSource/lfn/tools/kubernetes-status>`__;kubernetes python library +onap-k8s-teardown;Check common resources of the ONAP Kubernetes namespace after all tests execution;`python module <https://gitlab.com/Orange-OpenSource/lfn/tools/kubernetes-status>`__;kubernetes python library diff --git a/docs/files/csv/tests-security.csv b/docs/files/csv/tests-security.csv new file mode 100644 index 000000000..9d949a9e0 --- /dev/null +++ b/docs/files/csv/tests-security.csv @@ -0,0 +1,5 @@ +Tests;Description;Code;Comments +root_pods;check that pods are nor using root user or started as root; `bash script <https://git.onap.org/integration/xtesting/tree/security/scripts/check_security_root.sh>`__; kubectl +unlimitted_pods;check that limits are set for pods;`bash script <https://git.onap.org/integration/xtesting/tree/security/scripts/check_unlimitted_pods.sh>`__; kubectl +nonssl_endpoints;check that all public HTTP endpoints exposed in ONAP cluster use SSL tunnels;`Go script <https://git.onap.org/integration/plain/test/security/sslendpoints/main.go>`__;kubetl, nmap +nodeport_check_certs;This test list the nodeports and tries to get SSL information to evaluate the validity of the certificates (expiration and issuer) used on the nodeports;`python module <https://git.onap.org/integration/tree/test/security/check_certificates>`__;pyopenssl, kubernetes python libraries diff --git a/docs/files/csv/tests-smoke.csv b/docs/files/csv/tests-smoke.csv new file mode 100644 index 000000000..16ea7593e --- /dev/null +++ b/docs/files/csv/tests-smoke.csv @@ -0,0 +1,11 @@ +Tests;Description;Code;Comments +basic_vm;Onboard, distribute and instantiate an Openstack VM using à la carte BPMN, replaced the former basic_vm test;`code <https://git.onap.org/testsuite/pythonsdk-tests/tree/src/onaptests/scenario/basic_vm.py>`__;`onap_pythonsdk <https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk>`__, `pythonsdk-tests <https://git.onap.org/testsuite/pythonsdk-tests/tree/>`__ +basic_network;Onboard, distribute and instantiate a Neutron network;`code <https://git.onap.org/testsuite/pythonsdk-tests/tree/src/onaptests/scenario/basic_network.py>`__;`onap_pythonsdk <https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk>`__, `pythonsdk-tests <https://git.onap.org/testsuite/pythonsdk-tests/tree/>`__ +basic_cnf;Onboard (new), distribute and instantiate a Kubernetes pods;`code <https://git.onap.org/testsuite/pythonsdk-tests/tree/src/onaptests/scenario/basic_cnf.py>`__;`onap_pythonsdk <https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk>`__, `pythonsdk-tests <https://git.onap.org/testsuite/pythonsdk-tests/tree/>`__ +5gbulkpm;5G Bulk PM Usecase functionality. The test has been significantly enhanced in Honolulu;`code <https://git.onap.org/testsuite/tree/robot/testsuites/usecases/5gbulkpm.robot>`__;`robotframework <https://robotframework.org/>`__ +pnf-registrate;Executes the PNF registration test cases including setup and teardown;`code <https://git.onap.org/testsuite/tree/robot/testsuites/pnf-registration.robot>`__;`robotframework <https://robotframework.org/>`__ +cmpv2;CMPv2 Usecase functionality;`code <https://git.onap.org/testsuite/tree/robot/testsuites/cmpv2.robot>`__;`robotframework <https://robotframework.org/>`__ +basic_vm_macro;Instantiate a VM using macro bpmn;`code <https://git.onap.org/testsuite/pythonsdk-tests/tree/src/onaptests/scenario/basic_vm_macro.py>`__;`onap_pythonsdk <https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk>`__, `pythonsdk-tests <https://git.onap.org/testsuite/pythonsdk-tests/tree/>`__ +pnf_macro;Run PNF simulator, onboard, distribute and instantiate service including PNF;`code <https://git.onap.org/testsuite/pythonsdk-tests/tree/src/onaptests/scenario/pnf_macro.py>`__;`onap_pythonsdk <https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk>`__, `pythonsdk-tests <https://git.onap.org/testsuite/pythonsdk-tests/tree/>`__ +cds_resource_resolution;Upload blueprint file into CDS, execute test workflow and check results;`code <https://git.onap.org/testsuite/pythonsdk-tests/tree/src/onaptests/scenario/cds_resource_resolution.py>`__;`onap_pythonsdk <https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk>`__, `pythonsdk-tests <https://git.onap.org/testsuite/pythonsdk-tests/tree/>`__ +basic_cnf_macro;Onboard (new), distribute and instantiate a Kubernetes pods using SO's macro flow;`code <https://git.onap.org/testsuite/pythonsdk-tests/tree/src/onaptests/scenario/basic_cnf_macro.py>`__;`onap_pythonsdk <https://gitlab.com/Orange-OpenSource/lfn/onap/python-onapsdk>`__, `pythonsdk-tests <https://git.onap.org/testsuite/pythonsdk-tests/tree/>`__ diff --git a/docs/files/csv/usecases-deprecated.csv b/docs/files/csv/usecases-deprecated.csv new file mode 100644 index 000000000..a1c3b3b33 --- /dev/null +++ b/docs/files/csv/usecases-deprecated.csv @@ -0,0 +1,28 @@ +Use Case;Link;Last Valid Version;Comments +vFirewall with closed loop;:ref:`official doc <docs_vfw>`;Guilin;Shall still be OK in Honolulu but not tested yet +Scale Out;:ref:`official doc <docs_scaleout>`;Guilin;Shall still be OK in Honolulu but not tested yet +vCPE Use Case;:ref:`official doc <docs_vcpe>`;El Alto;No resources to test on Frankfurt +vIPsec with HPA Use Case;:ref:`official doc<docs_vipsec_hpa>`;El Alto;No resources to test on Frankfurt +Change Management Schedule Optimization;:ref:`official doc<docs_CM_schedule_optimizer>`;El Alto;No resources to test on Frankfurt +Change Management Flexible Designer and Orchestrator;:ref:`official doc<docs_CM_flexible_designer_orchestrator>`;El Alto;No resources to test on Frankfurt +vFirewall/vDNS with HPA;:ref:`official doc <docs_vfw_hpa>`;Frankfurt;No resources to test on Guilin +BBS (Broadband Service);:ref:`official doc <docs_bbs>`;Frankfurt;No resources to test on Guilin +vFirewall CNF with multicloud k8s plugin;:ref:`official doc <docs_vfw_edgex_multicloud_k8s>`;Frankfurt;No resources to test on Guilin +EdgeXFoundry CNF with multicloud k8s plugin;:ref:`official doc <docs_vfw_edgex_multicloud_k8s>`;Frankfurt;No resources to test on Guilin +vCPE with Tosca;:ref:`official doc <docs_vcpe_tosca_local>`;Frankfurt;No resources to test on Guilin +E2E Automation vLB with CDS;`wiki page <https://wiki.onap.org/pages/viewpage.action?pageId=71838891>`__; Frankfurt;No resources to test on Guilin +vFirewall In-Place Software Upgrade with Traffic Distribution;:ref:`official doc <docs_vfw_traffic>`;Frankfurt;APPC in maintenance mode +5G Bulk PM; :ref:`official doc <docs_5g_bulk_pm>`;Frankfurt;No tested in Guilin +5G NRM Network Resource Model (Configuration management);:ref:`official doc <docs_5G_NRM_Configuration>`;Frankfurt;No tested in Guilin +5G NETCONF configuration;:ref:`official doc <docs_5G_Configuration_over_NETCONF>`;Frankfurt;No tested in Guilin +PNF Software Upgrade using direct Netconf Yang interface with PNF;:ref:`official doc <docs_5g_pnf_software_upgrade>`;Frankfurt;No tested in Guilin +PNF Software Upgrade with EM with Ansible;:ref:`official doc <docs_5G_PNF_Software_Upgrade_ansible_with_EM>`;Frankfurt;No tested in Guilin +PNF Software Upgrade with EM with Netconf; :ref:`official doc <docs_5g_pnf_software_upgrade_netconf_with_EM>`;Frankfurt;No tested in Guilin +PNF Software Upgrade in association to schema updates; :ref:`official doc <docs_5G_PNF_Software_Upgrade_With_Schema_Update>`;Frankfurt;No tested in Guilin +VSP Compliance and Validation Check within SDC;`wiki page <https://wiki.onap.org/display/DW/VSP+Compliance+and+Validation+Check+within+SDC+%28Frankfurt%29+-+Phase+2#VSPComplianceandValidationCheckwithinSDC(Frankfurt)Phase2-VSPComplianceCheckwithinSDC-IntegrationTestPlan>`_;Frankfurt;No tested in Guilin +Enable PNF software version at onboarding;`wiki page <https://jira.onap.org/browse/REQ-88?src=confmacro>`__;Frankfurt;No tested in Guilin +xNF communication security enhancements; `wiki page <https://wiki.onap.org/display/DW/xNF+communication+security+enhancements+-+Tests+Description+and+Status>`__;Frankfurt;No tested in Guilin +ETSI Alignment SO plugin to support SOL003 to connect to an external VNFM;`wiki page <https://wiki.onap.org/display/DW/ETSI+Alignment+Support>`__;Frankfurt;No tested in Guilin +Integration of CDS as an Actor; `official doc <https://docs.onap.org/projects/onap-ccsdk-cds/en/latest/ui/designer-guide.html>`_;Frankfurt;No tested in Guilin +3rd Party Operational Domain Manager; `wiki page <https://wiki.onap.org/display/DW/Third-party+Operational+Domain+Manager>`__;Frankfurt;No tested in Guilin +Configuration & persistency; `wiki page <https://wiki.onap.org/pages/viewpage.action?pageId=64003184>`__;Frankfurt;No tested in Guilin diff --git a/docs/files/csv/usecases-functional-requirements.csv b/docs/files/csv/usecases-functional-requirements.csv new file mode 100644 index 000000000..6bb6494d7 --- /dev/null +++ b/docs/files/csv/usecases-functional-requirements.csv @@ -0,0 +1,3 @@ +Issue key;Summary;Contact;Comment +REQ-1215;E2E Network Slicing use case enhancements for Kohn release;Kevin Tang; +REQ-1212;5G SON use case enhancements for Kohn release;N.K. Shankaranarayanan; diff --git a/docs/files/csv/usecases-non-functional-requirements.csv b/docs/files/csv/usecases-non-functional-requirements.csv new file mode 100644 index 000000000..3b489ac43 --- /dev/null +++ b/docs/files/csv/usecases-non-functional-requirements.csv @@ -0,0 +1,5 @@ +Issue key;Summary;Contact;Comment +REQ-1267;General intent model and general intent interface requirements in R11;Keguang He; +REQ-1214;Maintenance and Enhancement of Intent-driven Closed-loop Autonomous Networks in R11;Dong Wang; +REQ-1268;CCVPN Kohn Enhancements for Intent-based Cloud Leased Line and Transport Slicing;Henry Yu; +REQ-1342;Retirement of unmaintained repos;Amy Zwarico;
\ No newline at end of file diff --git a/docs/files/csv/usecases-old-valid.csv b/docs/files/csv/usecases-old-valid.csv new file mode 100644 index 000000000..c10709e9d --- /dev/null +++ b/docs/files/csv/usecases-old-valid.csv @@ -0,0 +1,6 @@ +Summary;Link;Contacts +vFirewall CNF With CDS;:ref:`official doc <docs_vFW_CNF_CDS>`;L.Rajewski, K.Banka +5G Realtime PM and High Volume Stream Data Collection; :ref:`official doc <docs_realtime_pm>`;M.Przybysz +5G PNF Plug and Play; :ref:`official doc <docs_5g_pnf_pnp>`; M.Przybysz K.Kuzmicki +5G PNF Pre-Onboarding & Onboarding;:ref:`official doc <docs_pnf_onboarding_preonboarding>`;M.Przybysz K.Kuzmicki D.Melia A.Walshe +MDONS extension;:ref:`official doc <docs_CCVPN>`;X.Miao diff --git a/docs/files/csv/usecases.csv b/docs/files/csv/usecases.csv new file mode 100644 index 000000000..629088202 --- /dev/null +++ b/docs/files/csv/usecases.csv @@ -0,0 +1,4 @@ +Ref;Summary;Link;Contacts +REQ-440;E2E Network Slicing;:ref:`official doc <docs_E2E_network_slicing>`;Kevin Tang +REQ-429;5G OOF SON;:ref:`official doc <docs_5G_oof_son>`;N. K. Shankaranarayanan +REQ-459;CCVPN-Transport Slicing;:ref:`official doc <docs_ccvpn>`;Henry Yu diff --git a/docs/files/ns_automation/ns_automation_sdc_suffix.png b/docs/files/ns_automation/ns_automation_sdc_suffix.png Binary files differnew file mode 100644 index 000000000..c78d27230 --- /dev/null +++ b/docs/files/ns_automation/ns_automation_sdc_suffix.png diff --git a/docs/files/ns_automation/ns_automation_suc.png b/docs/files/ns_automation/ns_automation_suc.png Binary files differnew file mode 100644 index 000000000..ff7a6d9b4 --- /dev/null +++ b/docs/files/ns_automation/ns_automation_suc.png diff --git a/docs/files/ns_automation/ns_automation_test_class.png b/docs/files/ns_automation/ns_automation_test_class.png Binary files differnew file mode 100644 index 000000000..5f7976841 --- /dev/null +++ b/docs/files/ns_automation/ns_automation_test_class.png diff --git a/docs/files/s3p/basic_vm_duration.png b/docs/files/s3p/basic_vm_duration.png Binary files differnew file mode 100644 index 000000000..71e522681 --- /dev/null +++ b/docs/files/s3p/basic_vm_duration.png diff --git a/docs/files/s3p/basic_vm_duration_histo.png b/docs/files/s3p/basic_vm_duration_histo.png Binary files differnew file mode 100644 index 000000000..d201d3b81 --- /dev/null +++ b/docs/files/s3p/basic_vm_duration_histo.png diff --git a/docs/files/s3p/guilin_daily_healthcheck.png b/docs/files/s3p/guilin_daily_healthcheck.png Binary files differnew file mode 100644 index 000000000..34a58ebda --- /dev/null +++ b/docs/files/s3p/guilin_daily_healthcheck.png diff --git a/docs/files/s3p/guilin_daily_infrastructure_healthcheck.png b/docs/files/s3p/guilin_daily_infrastructure_healthcheck.png Binary files differnew file mode 100644 index 000000000..be24c02ce --- /dev/null +++ b/docs/files/s3p/guilin_daily_infrastructure_healthcheck.png diff --git a/docs/files/s3p/guilin_daily_security.png b/docs/files/s3p/guilin_daily_security.png Binary files differnew file mode 100644 index 000000000..1d3d518c0 --- /dev/null +++ b/docs/files/s3p/guilin_daily_security.png diff --git a/docs/files/s3p/guilin_daily_smoke.png b/docs/files/s3p/guilin_daily_smoke.png Binary files differnew file mode 100644 index 000000000..5200c575e --- /dev/null +++ b/docs/files/s3p/guilin_daily_smoke.png diff --git a/docs/files/s3p/honolulu_daily_healthcheck.png b/docs/files/s3p/honolulu_daily_healthcheck.png Binary files differnew file mode 100644 index 000000000..01216aee4 --- /dev/null +++ b/docs/files/s3p/honolulu_daily_healthcheck.png diff --git a/docs/files/s3p/honolulu_daily_infrastructure_healthcheck.png b/docs/files/s3p/honolulu_daily_infrastructure_healthcheck.png Binary files differnew file mode 100644 index 000000000..660902029 --- /dev/null +++ b/docs/files/s3p/honolulu_daily_infrastructure_healthcheck.png diff --git a/docs/files/s3p/honolulu_daily_security.png b/docs/files/s3p/honolulu_daily_security.png Binary files differnew file mode 100644 index 000000000..2efc9c84a --- /dev/null +++ b/docs/files/s3p/honolulu_daily_security.png diff --git a/docs/files/s3p/honolulu_daily_smoke.png b/docs/files/s3p/honolulu_daily_smoke.png Binary files differnew file mode 100644 index 000000000..4192e404d --- /dev/null +++ b/docs/files/s3p/honolulu_daily_smoke.png diff --git a/docs/files/s3p/honolulu_sdc_stability.png b/docs/files/s3p/honolulu_sdc_stability.png Binary files differnew file mode 100644 index 000000000..4d6c4ee2c --- /dev/null +++ b/docs/files/s3p/honolulu_sdc_stability.png diff --git a/docs/files/s3p/honolulu_sdc_stability_resources.png b/docs/files/s3p/honolulu_sdc_stability_resources.png Binary files differnew file mode 100644 index 000000000..dd9333687 --- /dev/null +++ b/docs/files/s3p/honolulu_sdc_stability_resources.png diff --git a/docs/files/s3p/honolulu_so_stability_1_duration.png b/docs/files/s3p/honolulu_so_stability_1_duration.png Binary files differnew file mode 100644 index 000000000..47f625604 --- /dev/null +++ b/docs/files/s3p/honolulu_so_stability_1_duration.png diff --git a/docs/files/s3p/honolulu_so_stability_5.png b/docs/files/s3p/honolulu_so_stability_5.png Binary files differnew file mode 100644 index 000000000..fe8487524 --- /dev/null +++ b/docs/files/s3p/honolulu_so_stability_5.png diff --git a/docs/files/s3p/honolulu_weekly_cpu.png b/docs/files/s3p/honolulu_weekly_cpu.png Binary files differnew file mode 100644 index 000000000..dbf55d272 --- /dev/null +++ b/docs/files/s3p/honolulu_weekly_cpu.png diff --git a/docs/files/s3p/honolulu_weekly_memory.png b/docs/files/s3p/honolulu_weekly_memory.png Binary files differnew file mode 100644 index 000000000..5cbdf04be --- /dev/null +++ b/docs/files/s3p/honolulu_weekly_memory.png diff --git a/docs/files/s3p/istanbul-dashboard.png b/docs/files/s3p/istanbul-dashboard.png Binary files differnew file mode 100644 index 000000000..f8bad42ad --- /dev/null +++ b/docs/files/s3p/istanbul-dashboard.png diff --git a/docs/files/s3p/istanbul_daily_healthcheck.png b/docs/files/s3p/istanbul_daily_healthcheck.png Binary files differnew file mode 100644 index 000000000..e1cf16ae6 --- /dev/null +++ b/docs/files/s3p/istanbul_daily_healthcheck.png diff --git a/docs/files/s3p/istanbul_daily_infrastructure_healthcheck.png b/docs/files/s3p/istanbul_daily_infrastructure_healthcheck.png Binary files differnew file mode 100644 index 000000000..1e8877d0e --- /dev/null +++ b/docs/files/s3p/istanbul_daily_infrastructure_healthcheck.png diff --git a/docs/files/s3p/istanbul_daily_security.png b/docs/files/s3p/istanbul_daily_security.png Binary files differnew file mode 100644 index 000000000..605edb140 --- /dev/null +++ b/docs/files/s3p/istanbul_daily_security.png diff --git a/docs/files/s3p/istanbul_daily_smoke.png b/docs/files/s3p/istanbul_daily_smoke.png Binary files differnew file mode 100644 index 000000000..cdeb999da --- /dev/null +++ b/docs/files/s3p/istanbul_daily_smoke.png diff --git a/docs/files/s3p/istanbul_instantiation_stability_10.png b/docs/files/s3p/istanbul_instantiation_stability_10.png Binary files differnew file mode 100644 index 000000000..73749572a --- /dev/null +++ b/docs/files/s3p/istanbul_instantiation_stability_10.png diff --git a/docs/files/s3p/istanbul_resiliency.png b/docs/files/s3p/istanbul_resiliency.png Binary files differnew file mode 100644 index 000000000..567a98c5c --- /dev/null +++ b/docs/files/s3p/istanbul_resiliency.png diff --git a/docs/files/s3p/istanbul_sdc_stability.png b/docs/files/s3p/istanbul_sdc_stability.png Binary files differnew file mode 100644 index 000000000..67346cb0d --- /dev/null +++ b/docs/files/s3p/istanbul_sdc_stability.png diff --git a/docs/files/s3p/jakarta-dashboard.png b/docs/files/s3p/jakarta-dashboard.png Binary files differnew file mode 100755 index 000000000..e5f2fd1b8 --- /dev/null +++ b/docs/files/s3p/jakarta-dashboard.png diff --git a/docs/files/s3p/stability_sdnc_memory.png b/docs/files/s3p/stability_sdnc_memory.png Binary files differnew file mode 100644 index 000000000..c381077f5 --- /dev/null +++ b/docs/files/s3p/stability_sdnc_memory.png diff --git a/docs/files/scaleout/latest-tca-guilin.yaml b/docs/files/scaleout/latest-tca-guilin.yaml new file mode 100644 index 000000000..e7d967a26 --- /dev/null +++ b/docs/files/scaleout/latest-tca-guilin.yaml @@ -0,0 +1,141 @@ +# ============LICENSE_START==================================================== +# ============================================================================= +# Copyright (C) 2019-2020 AT&T Intellectual Property. All rights reserved. +# ============================================================================= +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +# ============LICENSE_END====================================================== +#k8s-tca-gen2-v3.yaml + +tosca_definitions_version: cloudify_dsl_1_3 +imports: + - https://www.getcloudify.org/spec/cloudify/4.5.5/types.yaml + - plugin:k8splugin?version=3.4.2 + - plugin:clamppolicyplugin?version=1.1.0 +inputs: + service_name: + type: string + default: 'dcae-tcagen2' + log_directory: + type: string + default: "/opt/logs/dcae-analytics-tca" + replicas: + type: integer + description: number of instances + default: 1 + spring.data.mongodb.uri: + type: string + default: "mongodb://dcae-mongohost/dcae-tcagen2" + tag_version: + type: string + default: "nexus3.onap.org:10001/onap/org.onap.dcaegen2.analytics.tca-gen2.dcae-analytics-tca-web:1.2.1" + tca.aai.password: + type: string + default: "DCAE" + tca.aai.url: + type: string + default: "http://aai.onap.svc.cluster.local" + tca.aai.username: + type: string + default: "DCAE" + tca_handle_in_subscribe_url: + type: string + default: "http://message-router.onap.svc.cluster.local:3904/events/unauthenticated.VES_MEASUREMENT_OUTPUT" + tca_handle_out_publish_url: + type: string + default: "http://message-router.onap.svc.cluster.local:3904/events/unauthenticated.DCAE_CL_OUTPUT" + tca_consumer_group: + type: string + default: "cg1" + policy_model_id: + type: string + default: "onap.policies.monitoring.tcagen2" + policy_id: + type: string + default: "onap.restart.tca" +node_templates: + docker.tca: + type: dcae.nodes.ContainerizedServiceComponent + relationships: + - target: tcagen2_policy + type: cloudify.relationships.depends_on + interfaces: + cloudify.interfaces.lifecycle: + start: + inputs: + ports: + - concat: ["9091:", "0"] + properties: + application_config: + service_calls: [] + streams_publishes: + tca_handle_out: + dmaap_info: + topic_url: + get_input: tca_handle_out_publish_url + type: message_router + streams_subscribes: + tca_handle_in: + dmaap_info: + topic_url: + get_input: tca_handle_in_subscribe_url + type: message_router + spring.data.mongodb.uri: + get_input: spring.data.mongodb.uri + streams_subscribes.tca_handle_in.consumer_group: + get_input: tca_consumer_group + streams_subscribes.tca_handle_in.consumer_ids[0]: c0 + streams_subscribes.tca_handle_in.consumer_ids[1]: c1 + streams_subscribes.tca_handle_in.message_limit: 50000 + streams_subscribes.tca_handle_in.polling.auto_adjusting.max: 60000 + streams_subscribes.tca_handle_in.polling.auto_adjusting.min: 30000 + streams_subscribes.tca_handle_in.polling.auto_adjusting.step_down: 30000 + streams_subscribes.tca_handle_in.polling.auto_adjusting.step_up: 10000 + streams_subscribes.tca_handle_in.polling.fixed_rate: 0 + streams_subscribes.tca_handle_in.timeout: -1 + tca.aai.enable_enrichment: true + tca.aai.generic_vnf_path: aai/v11/network/generic-vnfs/generic-vnf + tca.aai.node_query_path: aai/v11/search/nodes-query + tca.aai.password: + get_input: tca.aai.password + tca.aai.url: + get_input: tca.aai.url + tca.aai.username: + get_input: tca.aai.username + tca.policy: '{"domain":"measurementsForVfScaling","metricsPerEventName":[{"eventName":"vFirewallBroadcastPackets","controlLoopSchemaType":"VM","policyScope":"DCAE","policyName":"DCAE.Config_tca-hi-lo","policyVersion":"v0.0.1","thresholds":[{"closedLoopControlName":"ControlLoop-vFirewall-d0a1dfc6-94f5-4fd4-a5b5-4630b438850a","version":"1.0.2","fieldPath":"$.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedTotalPacketsDelta","thresholdValue":300,"direction":"LESS_OR_EQUAL","severity":"MAJOR","closedLoopEventStatus":"ONSET"},{"closedLoopControlName":"ControlLoop-vFirewall-d0a1dfc6-94f5-4fd4-a5b5-4630b438850a","version":"1.0.2","fieldPath":"$.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedTotalPacketsDelta","thresholdValue":700,"direction":"GREATER_OR_EQUAL","severity":"CRITICAL","closedLoopEventStatus":"ONSET"}]},{"eventName":"vLoadBalancer","controlLoopSchemaType":"VM","policyScope":"DCAE","policyName":"DCAE.Config_tca-hi-lo","policyVersion":"v0.0.1","thresholds":[{"closedLoopControlName":"ControlLoop-vDNS-6f37f56d-a87d-4b85-b6a9-cc953cf779b3","version":"1.0.2","fieldPath":"$.event.measurementsForVfScalingFields.vNicPerformanceArray[*].receivedTotalPacketsDelta","thresholdValue":300,"direction":"GREATER_OR_EQUAL","severity":"CRITICAL","closedLoopEventStatus":"ONSET"}]},{"eventName":"Measurement_vGMUX","controlLoopSchemaType":"VNF","policyScope":"DCAE","policyName":"DCAE.Config_tca-hi-lo","policyVersion":"v0.0.1","thresholds":[{"closedLoopControlName":"ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e","version":"1.0.2","fieldPath":"$.event.measurementsForVfScalingFields.additionalMeasurements[*].arrayOfFields[0].value","thresholdValue":0,"direction":"EQUAL","severity":"MAJOR","closedLoopEventStatus":"ABATED"},{"closedLoopControlName":"ControlLoop-vCPE-48f0c2c3-a172-4192-9ae3-052274181b6e","version":"1.0.2","fieldPath":"$.event.measurementsForVfScalingFields.additionalMeasurements[*].arrayOfFields[0].value","thresholdValue":0,"direction":"GREATER","severity":"CRITICAL","closedLoopEventStatus":"ONSET"}]}]}' + tca.processing_batch_size: 10000 + tca.enable_abatement: true + tca.enable_ecomp_logging: true + docker_config: + healthcheck: + endpoint: /actuator/health + interval: 30s + timeout: 10s + type: http + image: + get_input: tag_version + log_info: + log_directory: + get_input: log_directory + tls_info: + use_tls: true + cert_directory: '/etc/tca-gen2/ssl' + replicas: + get_input: replicas + service_component_type: { get_input: service_name } + tcagen2_policy: + type: clamp.nodes.policy + properties: + policy_id: + get_input: policy_id + policy_model_id: + get_input: policy_model_id diff --git a/docs/files/simulators/NF-Simulator.png b/docs/files/simulators/NF-Simulator.png Binary files differnew file mode 100644 index 000000000..b52aaa5ff --- /dev/null +++ b/docs/files/simulators/NF-Simulator.png diff --git a/docs/files/softwareUpgrade/OnboardingCsar.png b/docs/files/softwareUpgrade/OnboardingCsar.png Binary files differnew file mode 100644 index 000000000..0a5ba2bfd --- /dev/null +++ b/docs/files/softwareUpgrade/OnboardingCsar.png diff --git a/docs/files/softwareUpgrade/SchemaUpdate.png b/docs/files/softwareUpgrade/SchemaUpdate.png Binary files differnew file mode 100644 index 000000000..25884bdcb --- /dev/null +++ b/docs/files/softwareUpgrade/SchemaUpdate.png diff --git a/docs/files/softwareUpgrade/ServiceLevelUpgrade.png b/docs/files/softwareUpgrade/ServiceLevelUpgrade.png Binary files differnew file mode 100644 index 000000000..86d856765 --- /dev/null +++ b/docs/files/softwareUpgrade/ServiceLevelUpgrade.png diff --git a/docs/files/softwareUpgrade/ServiceLevelWorkflow.png b/docs/files/softwareUpgrade/ServiceLevelWorkflow.png Binary files differnew file mode 100644 index 000000000..ea37d1603 --- /dev/null +++ b/docs/files/softwareUpgrade/ServiceLevelWorkflow.png diff --git a/docs/files/softwareUpgrade/WorkflowView.png b/docs/files/softwareUpgrade/WorkflowView.png Binary files differnew file mode 100644 index 000000000..79a28f1db --- /dev/null +++ b/docs/files/softwareUpgrade/WorkflowView.png diff --git a/docs/files/softwareUpgrade/serviceModelVersions.png b/docs/files/softwareUpgrade/serviceModelVersions.png Binary files differnew file mode 100644 index 000000000..a918ffa00 --- /dev/null +++ b/docs/files/softwareUpgrade/serviceModelVersions.png diff --git a/docs/files/softwareUpgrade/verifyPNF.png b/docs/files/softwareUpgrade/verifyPNF.png Binary files differnew file mode 100644 index 000000000..f0aacec9f --- /dev/null +++ b/docs/files/softwareUpgrade/verifyPNF.png diff --git a/docs/files/softwareUpgrade/workflowList.png b/docs/files/softwareUpgrade/workflowList.png Binary files differnew file mode 100644 index 000000000..339907ac5 --- /dev/null +++ b/docs/files/softwareUpgrade/workflowList.png diff --git a/docs/files/tests/test-basic-cnf.png b/docs/files/tests/test-basic-cnf.png Binary files differnew file mode 100644 index 000000000..87701587e --- /dev/null +++ b/docs/files/tests/test-basic-cnf.png diff --git a/docs/files/tests/test-certif.png b/docs/files/tests/test-certif.png Binary files differnew file mode 100644 index 000000000..69d6264c2 --- /dev/null +++ b/docs/files/tests/test-certif.png diff --git a/docs/files/tests/test-dashboard.png b/docs/files/tests/test-dashboard.png Binary files differnew file mode 100644 index 000000000..afd4eee49 --- /dev/null +++ b/docs/files/tests/test-dashboard.png diff --git a/docs/files/tests/test-onap-helm.png b/docs/files/tests/test-onap-helm.png Binary files differnew file mode 100644 index 000000000..e5f5b5366 --- /dev/null +++ b/docs/files/tests/test-onap-helm.png diff --git a/docs/files/tests/test-onap-k8s.png b/docs/files/tests/test-onap-k8s.png Binary files differnew file mode 100644 index 000000000..69693f7f5 --- /dev/null +++ b/docs/files/tests/test-onap-k8s.png diff --git a/docs/files/vFW_CNF_CDS/Native_Helm_Flow.png b/docs/files/vFW_CNF_CDS/Native_Helm_Flow.png Binary files differnew file mode 100644 index 000000000..7e896aa8c --- /dev/null +++ b/docs/files/vFW_CNF_CDS/Native_Helm_Flow.png diff --git a/docs/files/vFW_CNF_CDS/healthcheck.png b/docs/files/vFW_CNF_CDS/healthcheck.png Binary files differnew file mode 100644 index 000000000..693e9e74c --- /dev/null +++ b/docs/files/vFW_CNF_CDS/healthcheck.png diff --git a/docs/files/vFW_CNF_CDS/helm-overrides-steps.png b/docs/files/vFW_CNF_CDS/helm-overrides-steps.png Binary files differnew file mode 100644 index 000000000..ad9355344 --- /dev/null +++ b/docs/files/vFW_CNF_CDS/helm-overrides-steps.png diff --git a/docs/files/vFW_CNF_CDS/helm-overrides.png b/docs/files/vFW_CNF_CDS/helm-overrides.png Binary files differnew file mode 100644 index 000000000..93a4a34c5 --- /dev/null +++ b/docs/files/vFW_CNF_CDS/helm-overrides.png diff --git a/docs/files/vFW_CNF_CDS/k8s-resources-response.json b/docs/files/vFW_CNF_CDS/k8s-resources-response.json new file mode 100644 index 000000000..3d0f91344 --- /dev/null +++ b/docs/files/vFW_CNF_CDS/k8s-resources-response.json @@ -0,0 +1,843 @@ +{ + "k8s-resource": [ + { + "id": "e5a4eca381ade9439806cf426eb7a07237fe9a8c9088038bd0c8135f728fabe2", + "name": "vfw-1-vfw", + "group": "apps", + "version": "v1", + "kind": "Deployment", + "namespace": "vfirewall", + "labels": [ + "chart=vfw", + "k8splugin.io/rb-instance-id=brave_brattain", + "release=vfw-1-vfw", + "vf-module-name=vfw-1-vfw", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/brave_brattain/query?ApiVersion=v1&Kind=Deployment&Name=vfw-1-vfw&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35940985", + "resource-version": "1635943384048", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/d56c54b9-40cc-4b7a-abce-50454571e39d", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "d56c54b9-40cc-4b7a-abce-50454571e39d" + } + ] + } + ] + } + }, + { + "id": "5b43d0c6e6b3ebb3d279dccbdad024a02995d0e66c2858c866ba9295c34cde62", + "name": "vfw-1-vsn-5f45887f5f-khqdd", + "group": "", + "version": "v1", + "kind": "Pod", + "namespace": "vfirewall", + "labels": [ + "chart=vsn", + "k8splugin.io/rb-instance-id=sharp_torvalds", + "pod-template-hash=5f45887f5f", + "release=vfw-1-vsn", + "vf-module-name=vfw-1-vsn", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/sharp_torvalds/query?ApiVersion=v1&Kind=Pod&Name=vfw-1-vsn-5f45887f5f-khqdd&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35941084", + "resource-version": "1635943399747", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/56f3d02b-5a32-4a97-9e7b-d3c0094c07e8", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "56f3d02b-5a32-4a97-9e7b-d3c0094c07e8" + } + ] + } + ] + } + }, + { + "id": "afce111381db5b5e61d12726d96e4d08b5dc1c7fdb5b069a24bb68c36314d45f", + "name": "kud-lr-onap-nf-20211103t124217642438z-ovn-nat", + "group": "k8s.cni.cncf.io", + "version": "v1", + "kind": "NetworkAttachmentDefinition", + "namespace": "vfirewall", + "labels": [ + "chart=base_template", + "k8splugin.io/rb-instance-id=nifty_lichterman", + "release=vfw-1-base", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/nifty_lichterman/query?ApiVersion=v1&Kind=NetworkAttachmentDefinition&Name=kud-lr-onap-nf-20211103t124217642438z-ovn-nat&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35940925", + "resource-version": "1635943376139", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/abb282c8-c932-45dc-9c62-01938eab32fa", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "abb282c8-c932-45dc-9c62-01938eab32fa" + } + ] + } + ] + } + }, + { + "id": "eaa4c964f1e0559cb061cd543c381e8067fc19524195e04ca25b539fdde19712", + "name": "kud-lr-onap-nf-20211103t124217642438z-unprotected-network", + "group": "k8s.plugin.opnfv.org", + "version": "v1alpha1", + "kind": "Network", + "namespace": "vfirewall", + "labels": [ + "chart=base_template", + "k8splugin.io/rb-instance-id=nifty_lichterman", + "release=vfw-1-base", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/nifty_lichterman/query?ApiVersion=v1alpha1&Kind=Network&Name=kud-lr-onap-nf-20211103t124217642438z-unprotected-network&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35940922", + "resource-version": "1635943376139", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/abb282c8-c932-45dc-9c62-01938eab32fa", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "abb282c8-c932-45dc-9c62-01938eab32fa" + } + ] + } + ] + } + }, + { + "id": "6e5fc95d95eee51f818cd3fbd8fbd40bc29d9fe4c587a1e2840ef4d17fb2fac6", + "name": "vfw-1-vsn-configmap", + "group": "", + "version": "v1", + "kind": "ConfigMap", + "namespace": "vfirewall", + "labels": [ + "chart=vsn", + "k8splugin.io/rb-instance-id=sharp_torvalds", + "release=vfw-1-vsn", + "vf-module-name=vfw-1-vsn", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/sharp_torvalds/query?ApiVersion=v1&Kind=ConfigMap&Name=vfw-1-vsn-configmap&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35941065", + "resource-version": "1635943399747", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/56f3d02b-5a32-4a97-9e7b-d3c0094c07e8", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "56f3d02b-5a32-4a97-9e7b-d3c0094c07e8" + } + ] + } + ] + } + }, + { + "id": "9e587e69bfe74762f66c59c5cb2ed41ca37bafa59b454b4e1432f4c61f0361f7", + "name": "kud-lr-onap-nf-20211103t124217642438z-management-network", + "group": "k8s.plugin.opnfv.org", + "version": "v1alpha1", + "kind": "Network", + "namespace": "vfirewall", + "labels": [ + "chart=base_template", + "k8splugin.io/rb-instance-id=nifty_lichterman", + "release=vfw-1-base", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/nifty_lichterman/query?ApiVersion=v1alpha1&Kind=Network&Name=kud-lr-onap-nf-20211103t124217642438z-management-network&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35940926", + "resource-version": "1635943376139", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/abb282c8-c932-45dc-9c62-01938eab32fa", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "abb282c8-c932-45dc-9c62-01938eab32fa" + } + ] + } + ] + } + }, + { + "id": "20413fe7d44e703f3b498a442184b7e95a1e52afccf68cdc5785bfb1855a70c9", + "name": "vfw-1-vfw-configmap", + "group": "", + "version": "v1", + "kind": "ConfigMap", + "namespace": "vfirewall", + "labels": [ + "chart=vfw", + "k8splugin.io/rb-instance-id=brave_brattain", + "release=vfw-1-vfw", + "vf-module-name=vfw-1-vfw", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/brave_brattain/query?ApiVersion=v1&Kind=ConfigMap&Name=vfw-1-vfw-configmap&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35940973", + "resource-version": "1635943384048", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/d56c54b9-40cc-4b7a-abce-50454571e39d", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "d56c54b9-40cc-4b7a-abce-50454571e39d" + } + ] + } + ] + } + }, + { + "id": "e73732351195c8c10d28413ddff1d968bd53b0b0e395c24b3b0fcd39f46ea730", + "name": "vfw-1-vpkg-mgmt", + "group": "", + "version": "v1", + "kind": "Service", + "namespace": "vfirewall", + "labels": [ + "chart=vpkg", + "k8splugin.io/rb-instance-id=dazzling_nightingale", + "release=vfw-1-vpkg", + "vf-module-name=vfw-1-vpkg", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/dazzling_nightingale/query?ApiVersion=v1&Kind=Service&Name=vfw-1-vpkg-mgmt&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35941017", + "resource-version": "1635943391652", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/314795d7-6005-4462-a9fe-7006538e3ff9", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "314795d7-6005-4462-a9fe-7006538e3ff9" + } + ] + } + ] + } + }, + { + "id": "f65235da9cb098588b2db0c9e7da1ccb00954268fba6bd621bb9ef0b48cd717f", + "name": "vfw-1-vpkg", + "group": "apps", + "version": "v1", + "kind": "Deployment", + "namespace": "vfirewall", + "labels": [ + "chart=vpkg", + "k8splugin.io/rb-instance-id=dazzling_nightingale", + "release=vfw-1-vpkg", + "vf-module-name=vfw-1-vpkg", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/dazzling_nightingale/query?ApiVersion=v1&Kind=Deployment&Name=vfw-1-vpkg&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35941032", + "resource-version": "1635943391652", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/314795d7-6005-4462-a9fe-7006538e3ff9", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "314795d7-6005-4462-a9fe-7006538e3ff9" + } + ] + } + ] + } + }, + { + "id": "87cbdb83bf436703bdb9823e07e1498a7b3ec7fb12ba14193aadd4630649e0ae", + "name": "vfw-1-vpkg-c6bdb954c-mlpz9", + "group": "", + "version": "v1", + "kind": "Pod", + "namespace": "vfirewall", + "labels": [ + "chart=vpkg", + "k8splugin.io/rb-instance-id=dazzling_nightingale", + "pod-template-hash=c6bdb954c", + "release=vfw-1-vpkg", + "vf-module-name=vfw-1-vpkg", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/dazzling_nightingale/query?ApiVersion=v1&Kind=Pod&Name=vfw-1-vpkg-c6bdb954c-mlpz9&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35941033", + "resource-version": "1635943391652", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/314795d7-6005-4462-a9fe-7006538e3ff9", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "314795d7-6005-4462-a9fe-7006538e3ff9" + } + ] + } + ] + } + }, + { + "id": "8c8a65ef11c599eb15a1054ccd590a94305d52d2efa1e72c7581ee2094cace1b", + "name": "vfw-1-vsn", + "group": "apps", + "version": "v1", + "kind": "Deployment", + "namespace": "vfirewall", + "labels": [ + "chart=vsn", + "k8splugin.io/rb-instance-id=sharp_torvalds", + "release=vfw-1-vsn", + "vf-module-name=vfw-1-vsn", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/sharp_torvalds/query?ApiVersion=v1&Kind=Deployment&Name=vfw-1-vsn&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35941083", + "resource-version": "1635943399747", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/56f3d02b-5a32-4a97-9e7b-d3c0094c07e8", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "56f3d02b-5a32-4a97-9e7b-d3c0094c07e8" + } + ] + } + ] + } + }, + { + "id": "677e61310b562007084bc99c42aefb9106438d4c782afc6504d6a6a062b974a8", + "name": "kud-lr-onap-nf-20211103t124217642438z-protected-network", + "group": "k8s.plugin.opnfv.org", + "version": "v1alpha1", + "kind": "Network", + "namespace": "vfirewall", + "labels": [ + "chart=base_template", + "k8splugin.io/rb-instance-id=nifty_lichterman", + "release=vfw-1-base", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/nifty_lichterman/query?ApiVersion=v1alpha1&Kind=Network&Name=kud-lr-onap-nf-20211103t124217642438z-protected-network&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35940927", + "resource-version": "1635943376139", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/abb282c8-c932-45dc-9c62-01938eab32fa", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "abb282c8-c932-45dc-9c62-01938eab32fa" + } + ] + } + ] + } + }, + { + "id": "5538b19871da1fd05b82366c38cbbe88bae4d3444b6a21018f83787327958617", + "name": "vfw-1-vpkg-configmap", + "group": "", + "version": "v1", + "kind": "ConfigMap", + "namespace": "vfirewall", + "labels": [ + "chart=vpkg", + "k8splugin.io/rb-instance-id=dazzling_nightingale", + "release=vfw-1-vpkg", + "vf-module-name=vfw-1-vpkg", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/dazzling_nightingale/query?ApiVersion=v1&Kind=ConfigMap&Name=vfw-1-vpkg-configmap&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35941014", + "resource-version": "1635943391652", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/314795d7-6005-4462-a9fe-7006538e3ff9", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "314795d7-6005-4462-a9fe-7006538e3ff9" + } + ] + } + ] + } + }, + { + "id": "6134c369330c7398807d550c708890b0bcef2affbe5af1f9acde02c5a58c104a", + "name": "vfw-1-vsn-ui", + "group": "", + "version": "v1", + "kind": "Service", + "namespace": "vfirewall", + "labels": [ + "chart=vsn", + "k8splugin.io/rb-instance-id=sharp_torvalds", + "release=vfw-1-vsn", + "vf-module-name=vfw-1-vsn", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/sharp_torvalds/query?ApiVersion=v1&Kind=Service&Name=vfw-1-vsn-ui&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35941068", + "resource-version": "1635943399747", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/56f3d02b-5a32-4a97-9e7b-d3c0094c07e8", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "56f3d02b-5a32-4a97-9e7b-d3c0094c07e8" + } + ] + } + ] + } + }, + { + "id": "633a8c14f7df72b14f4d8e7b77cf7a2f33b71d54136e8582f135678c586fcde3", + "name": "vfw-1-vfw-89bd4bfdb-mshpq", + "group": "", + "version": "v1", + "kind": "Pod", + "namespace": "vfirewall", + "labels": [ + "chart=vfw", + "k8splugin.io/rb-instance-id=brave_brattain", + "pod-template-hash=89bd4bfdb", + "release=vfw-1-vfw", + "vf-module-name=vfw-1-vfw", + "vnf-name=test-vnf" + ], + "selflink": "http://so-cnf-adapter:8090/api/cnf-adapter/v1/instance/brave_brattain/query?ApiVersion=v1&Kind=Pod&Name=vfw-1-vfw-89bd4bfdb-mshpq&Namespace=vfirewall", + "data-owner": "CnfAdapter", + "data-source": "K8sPlugin", + "data-source-version": "35940986", + "resource-version": "1635943384048", + "relationship-list": { + "relationship": [ + { + "related-to": "generic-vnf", + "relationship-label": "tosca.relationships.HostedOn", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + } + ], + "related-to-property": [ + { + "property-key": "generic-vnf.vnf-name", + "property-value": "VF_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "vf-module", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/network/generic-vnfs/generic-vnf/d4af22f0-70e6-47ac-8d5b-4d645fc25757/vf-modules/vf-module/d56c54b9-40cc-4b7a-abce-50454571e39d", + "relationship-data": [ + { + "relationship-key": "generic-vnf.vnf-id", + "relationship-value": "d4af22f0-70e6-47ac-8d5b-4d645fc25757" + }, + { + "relationship-key": "vf-module.vf-module-id", + "relationship-value": "d56c54b9-40cc-4b7a-abce-50454571e39d" + } + ] + } + ] + } + } + ] +} diff --git a/docs/files/vFW_CNF_CDS/logs.zip b/docs/files/vFW_CNF_CDS/logs.zip Binary files differdeleted file mode 100644 index 0bfd75644..000000000 --- a/docs/files/vFW_CNF_CDS/logs.zip +++ /dev/null diff --git a/docs/files/vFW_CNF_CDS/profile-templating.png b/docs/files/vFW_CNF_CDS/profile-templating.png Binary files differnew file mode 100644 index 000000000..a60b040fe --- /dev/null +++ b/docs/files/vFW_CNF_CDS/profile-templating.png diff --git a/docs/files/vFW_CNF_CDS/scenarios.png b/docs/files/vFW_CNF_CDS/scenarios.png Binary files differnew file mode 100644 index 000000000..53da8668d --- /dev/null +++ b/docs/files/vFW_CNF_CDS/scenarios.png diff --git a/docs/files/vFW_CNF_CDS/status-response.json b/docs/files/vFW_CNF_CDS/status-response.json new file mode 100644 index 000000000..78b6c836d --- /dev/null +++ b/docs/files/vFW_CNF_CDS/status-response.json @@ -0,0 +1,1213 @@ +{ + "request": { + "rb-name": "vfw", + "rb-version": "plugin_test", + "profile-name": "test_profile", + "release-name": "", + "cloud-region": "kud", + "labels": { + "testCaseName": "plugin_fw.sh" + }, + "override-values": { + "global.onapPrivateNetworkName": "onap-private-net-test" + } + }, + "ready": false, + "resourceCount": 12, + "resourcesStatus": [ + { + "name": "sink-configmap", + "GVK": { + "Group": "", + "Version": "v1", + "Kind": "ConfigMap" + }, + "status": { + "apiVersion": "v1", + "data": { + "protected_net_gw": "192.168.20.100", + "protected_private_net_cidr": "192.168.10.0/24" + }, + "kind": "ConfigMap", + "metadata": { + "creationTimestamp": "2020-09-29T13:36:25Z", + "labels": { + "k8splugin.io/rb-instance-id": "practical_nobel" + }, + "name": "sink-configmap", + "namespace": "plugin-tests-namespace", + "resourceVersion": "10720771", + "selfLink": "/api/v1/namespaces/plugin-tests-namespace/configmaps/sink-configmap", + "uid": "46c8bec4-980c-455b-9eb0-fb84ac8cc450" + } + } + }, + { + "name": "packetgen-service", + "GVK": { + "Group": "", + "Version": "v1", + "Kind": "Service" + }, + "status": { + "apiVersion": "v1", + "kind": "Service", + "metadata": { + "creationTimestamp": "2020-09-29T13:36:25Z", + "labels": { + "app": "packetgen", + "chart": "packetgen", + "k8splugin.io/rb-instance-id": "practical_nobel", + "release": "test-release" + }, + "name": "packetgen-service", + "namespace": "plugin-tests-namespace", + "resourceVersion": "10720776", + "selfLink": "/api/v1/namespaces/plugin-tests-namespace/services/packetgen-service", + "uid": "5e1c27c8-1db8-4883-a3a2-6f4e98e2f48b" + }, + "spec": { + "clusterIP": "10.244.8.190", + "externalTrafficPolicy": "Cluster", + "ports": [ + { + "nodePort": 30831, + "port": 2831, + "protocol": "TCP", + "targetPort": 2831 + } + ], + "selector": { + "app": "packetgen", + "release": "test-release" + }, + "sessionAffinity": "None", + "type": "NodePort" + }, + "status": { + "loadBalancer": {} + } + } + }, + { + "name": "sink-service", + "GVK": { + "Group": "", + "Version": "v1", + "Kind": "Service" + }, + "status": { + "apiVersion": "v1", + "kind": "Service", + "metadata": { + "creationTimestamp": "2020-09-29T13:36:25Z", + "labels": { + "app": "sink", + "chart": "sink", + "k8splugin.io/rb-instance-id": "practical_nobel", + "release": "test-release" + }, + "name": "sink-service", + "namespace": "plugin-tests-namespace", + "resourceVersion": "10720780", + "selfLink": "/api/v1/namespaces/plugin-tests-namespace/services/sink-service", + "uid": "789a14fe-1246-4cdd-ba9a-359240ba614f" + }, + "spec": { + "clusterIP": "10.244.2.4", + "externalTrafficPolicy": "Cluster", + "ports": [ + { + "nodePort": 30667, + "port": 667, + "protocol": "TCP", + "targetPort": 667 + } + ], + "selector": { + "app": "sink", + "release": "test-release" + }, + "sessionAffinity": "None", + "type": "NodePort" + }, + "status": { + "loadBalancer": {} + } + } + }, + { + "name": "test-release-packetgen", + "GVK": { + "Group": "apps", + "Version": "v1", + "Kind": "Deployment" + }, + "status": { + "apiVersion": "apps/v1", + "kind": "Deployment", + "metadata": { + "annotations": { + "deployment.kubernetes.io/revision": "1" + }, + "creationTimestamp": "2020-09-29T13:36:25Z", + "generation": 1, + "labels": { + "app": "packetgen", + "chart": "packetgen", + "k8splugin.io/rb-instance-id": "practical_nobel", + "release": "test-release" + }, + "name": "test-release-packetgen", + "namespace": "plugin-tests-namespace", + "resourceVersion": "10720804", + "selfLink": "/apis/apps/v1/namespaces/plugin-tests-namespace/deployments/test-release-packetgen", + "uid": "42578e9f-7c88-46d6-94f7-a7bcc8e69ec6" + }, + "spec": { + "progressDeadlineSeconds": 600, + "replicas": 1, + "revisionHistoryLimit": 10, + "selector": { + "matchLabels": { + "app": "packetgen", + "release": "test-release" + } + }, + "strategy": { + "rollingUpdate": { + "maxSurge": "25%", + "maxUnavailable": "25%" + }, + "type": "RollingUpdate" + }, + "template": { + "metadata": { + "annotations": { + "VirtletCloudInitUserData": "ssh_pwauth: True\nusers:\n- name: admin\n gecos: User\n primary-group: admin\n groups: users\n sudo: ALL=(ALL) NOPASSWD:ALL\n lock_passwd: false\n passwd: \"$6$rounds=4096$QA5OCKHTE41$jRACivoPMJcOjLRgxl3t.AMfU7LhCFwOWv2z66CQX.TSxBy50JoYtycJXSPr2JceG.8Tq/82QN9QYt3euYEZW/\"\nruncmd:\n - export demo_artifacts_version=1.5.0\n - export vfw_private_ip_0=192.168.10.3\n - export vsn_private_ip_0=192.168.20.3\n - export protected_net_cidr=192.168.20.0/24\n - export dcae_collector_ip=10.0.4.1\n - export dcae_collector_port=8081\n - export protected_net_gw=192.168.20.100/24\n - export protected_private_net_cidr=192.168.10.0/24\n - wget -O - https://git.onap.org/multicloud/k8s/plain/kud/tests/vFW/packetgen | sudo -E bash\n", + "VirtletLibvirtCPUSetting": "mode: host-model\n", + "VirtletRootVolumeSize": "5Gi", + "app": "packetgen", + "k8s.plugin.opnfv.org/nfn-network": "{ \"type\": \"ovn4nfv\", \"interface\":[ { \"name\": \"unprotected-private-net\", \"ipAddress\": \"192.168.10.2\", \"interface\": \"eth1\" , \"defaultGateway\": \"false\"}, { \"name\": \"onap-private-net-test\", \"ipAddress\": \"10.0.100.2\", \"interface\": \"eth2\" , \"defaultGateway\": \"false\"} ]}", + "k8s.v1.cni.cncf.io/networks": "[{\"name\": \"ovn-networkobj\", \"namespace\": \"default\"}]", + "kubernetes.io/target-runtime": "virtlet.cloud", + "release": "test-release" + }, + "creationTimestamp": null, + "labels": { + "app": "packetgen", + "k8splugin.io/rb-instance-id": "practical_nobel", + "release": "test-release" + } + }, + "spec": { + "affinity": { + "nodeAffinity": { + "requiredDuringSchedulingIgnoredDuringExecution": { + "nodeSelectorTerms": [ + { + "matchExpressions": [ + { + "key": "extraRuntime", + "operator": "In", + "values": [ + "virtlet" + ] + } + ] + } + ] + } + } + }, + "containers": [ + { + "image": "virtlet.cloud/ubuntu/16.04:latest", + "imagePullPolicy": "IfNotPresent", + "name": "packetgen", + "resources": { + "limits": { + "memory": "4Gi" + } + }, + "stdin": true, + "terminationMessagePath": "/dev/termination-log", + "terminationMessagePolicy": "File", + "tty": true + } + ], + "dnsPolicy": "ClusterFirst", + "restartPolicy": "Always", + "schedulerName": "default-scheduler", + "securityContext": {}, + "terminationGracePeriodSeconds": 30 + } + } + }, + "status": { + "conditions": [ + { + "lastTransitionTime": "2020-09-29T13:36:25Z", + "lastUpdateTime": "2020-09-29T13:36:25Z", + "message": "Deployment does not have minimum availability.", + "reason": "MinimumReplicasUnavailable", + "status": "False", + "type": "Available" + }, + { + "lastTransitionTime": "2020-09-29T13:36:25Z", + "lastUpdateTime": "2020-09-29T13:36:25Z", + "message": "ReplicaSet \"test-release-packetgen-5647bfb56\" is progressing.", + "reason": "ReplicaSetUpdated", + "status": "True", + "type": "Progressing" + } + ], + "observedGeneration": 1, + "replicas": 1, + "unavailableReplicas": 1, + "updatedReplicas": 1 + } + } + }, + { + "name": "test-release-sink", + "GVK": { + "Group": "apps", + "Version": "v1", + "Kind": "Deployment" + }, + "status": { + "apiVersion": "apps/v1", + "kind": "Deployment", + "metadata": { + "annotations": { + "deployment.kubernetes.io/revision": "1" + }, + "creationTimestamp": "2020-09-29T13:36:25Z", + "generation": 1, + "labels": { + "app": "sink", + "chart": "sink", + "k8splugin.io/rb-instance-id": "practical_nobel", + "release": "test-release" + }, + "name": "test-release-sink", + "namespace": "plugin-tests-namespace", + "resourceVersion": "10720857", + "selfLink": "/apis/apps/v1/namespaces/plugin-tests-namespace/deployments/test-release-sink", + "uid": "1f50eecf-c924-4434-be87-daf7c64b6506" + }, + "spec": { + "progressDeadlineSeconds": 600, + "replicas": 1, + "revisionHistoryLimit": 10, + "selector": { + "matchLabels": { + "app": "sink", + "release": "test-release" + } + }, + "strategy": { + "rollingUpdate": { + "maxSurge": "25%", + "maxUnavailable": "25%" + }, + "type": "RollingUpdate" + }, + "template": { + "metadata": { + "annotations": { + "k8s.plugin.opnfv.org/nfn-network": "{ \"type\": \"ovn4nfv\", \"interface\": [ { \"name\": \"protected-private-net\", \"ipAddress\": \"192.168.20.3\", \"interface\": \"eth1\", \"defaultGateway\": \"false\" }, { \"name\": \"onap-private-net-test\", \"ipAddress\": \"10.10.100.4\", \"interface\": \"eth2\" , \"defaultGateway\": \"false\"} ]}", + "k8s.v1.cni.cncf.io/networks": "[{\"name\": \"ovn-networkobj\", \"namespace\": \"default\"}]" + }, + "creationTimestamp": null, + "labels": { + "app": "sink", + "k8splugin.io/rb-instance-id": "practical_nobel", + "release": "test-release" + } + }, + "spec": { + "containers": [ + { + "envFrom": [ + { + "configMapRef": { + "name": "sink-configmap" + } + } + ], + "image": "rtsood/onap-vfw-demo-sink:0.2.0", + "imagePullPolicy": "IfNotPresent", + "name": "sink", + "resources": {}, + "securityContext": { + "privileged": true + }, + "stdin": true, + "terminationMessagePath": "/dev/termination-log", + "terminationMessagePolicy": "File", + "tty": true + }, + { + "image": "electrocucaracha/darkstat:latest", + "imagePullPolicy": "IfNotPresent", + "name": "darkstat", + "ports": [ + { + "containerPort": 667, + "protocol": "TCP" + } + ], + "resources": {}, + "stdin": true, + "terminationMessagePath": "/dev/termination-log", + "terminationMessagePolicy": "File", + "tty": true + } + ], + "dnsPolicy": "ClusterFirst", + "restartPolicy": "Always", + "schedulerName": "default-scheduler", + "securityContext": {}, + "terminationGracePeriodSeconds": 30 + } + } + }, + "status": { + "availableReplicas": 1, + "conditions": [ + { + "lastTransitionTime": "2020-09-29T13:36:33Z", + "lastUpdateTime": "2020-09-29T13:36:33Z", + "message": "Deployment has minimum availability.", + "reason": "MinimumReplicasAvailable", + "status": "True", + "type": "Available" + }, + { + "lastTransitionTime": "2020-09-29T13:36:25Z", + "lastUpdateTime": "2020-09-29T13:36:33Z", + "message": "ReplicaSet \"test-release-sink-6546c4f698\" has successfully progressed.", + "reason": "NewReplicaSetAvailable", + "status": "True", + "type": "Progressing" + } + ], + "observedGeneration": 1, + "readyReplicas": 1, + "replicas": 1, + "updatedReplicas": 1 + } + } + }, + { + "name": "test-release-firewall", + "GVK": { + "Group": "apps", + "Version": "v1", + "Kind": "Deployment" + }, + "status": { + "apiVersion": "apps/v1", + "kind": "Deployment", + "metadata": { + "annotations": { + "deployment.kubernetes.io/revision": "1" + }, + "creationTimestamp": "2020-09-29T13:36:25Z", + "generation": 1, + "labels": { + "app": "firewall", + "chart": "firewall", + "k8splugin.io/rb-instance-id": "practical_nobel", + "release": "test-release" + }, + "name": "test-release-firewall", + "namespace": "plugin-tests-namespace", + "resourceVersion": "10720823", + "selfLink": "/apis/apps/v1/namespaces/plugin-tests-namespace/deployments/test-release-firewall", + "uid": "77392f60-7d12-4846-8edb-f4a65a4be098" + }, + "spec": { + "progressDeadlineSeconds": 600, + "replicas": 1, + "revisionHistoryLimit": 10, + "selector": { + "matchLabels": { + "app": "firewall", + "release": "test-release" + } + }, + "strategy": { + "rollingUpdate": { + "maxSurge": "25%", + "maxUnavailable": "25%" + }, + "type": "RollingUpdate" + }, + "template": { + "metadata": { + "annotations": { + "VirtletCloudInitUserData": "ssh_pwauth: True\nusers:\n- name: admin\n gecos: User\n primary-group: admin\n groups: users\n sudo: ALL=(ALL) NOPASSWD:ALL\n lock_passwd: false\n passwd: \"$6$rounds=4096$QA5OCKHTE41$jRACivoPMJcOjLRgxl3t.AMfU7LhCFwOWv2z66CQX.TSxBy50JoYtycJXSPr2JceG.8Tq/82QN9QYt3euYEZW/\"\nruncmd:\n - export demo_artifacts_version=1.5.0\n - export vfw_private_ip_0=192.168.10.3\n - export vsn_private_ip_0=192.168.20.3\n - export protected_net_cidr=192.168.20.0/24\n - export dcae_collector_ip=10.0.4.1\n - export dcae_collector_port=8081\n - export protected_net_gw=192.168.20.100/24\n - export protected_private_net_cidr=192.168.10.0/24\n - wget -O - https://git.onap.org/multicloud/k8s/plain/kud/tests/vFW/firewall | sudo -E bash\n", + "VirtletLibvirtCPUSetting": "mode: host-model\n", + "VirtletRootVolumeSize": "5Gi", + "k8s.plugin.opnfv.org/nfn-network": "{ \"type\": \"ovn4nfv\", \"interface\": [ { \"name\": \"unprotected-private-net\", \"ipAddress\": \"192.168.10.3\", \"interface\": \"eth1\" , \"defaultGateway\": \"false\"}, { \"name\": \"protected-private-net\", \"ipAddress\": \"192.168.20.2\", \"interface\": \"eth2\", \"defaultGateway\": \"false\" }, { \"name\": \"onap-private-net-test\", \"ipAddress\": \"10.10.100.3\", \"interface\": \"eth3\" , \"defaultGateway\": \"false\"} ]}", + "k8s.v1.cni.cncf.io/networks": "[{\"name\": \"ovn-networkobj\", \"namespace\": \"default\"}]", + "kubernetes.io/target-runtime": "virtlet.cloud" + }, + "creationTimestamp": null, + "labels": { + "app": "firewall", + "k8splugin.io/rb-instance-id": "practical_nobel", + "release": "test-release" + } + }, + "spec": { + "affinity": { + "nodeAffinity": { + "requiredDuringSchedulingIgnoredDuringExecution": { + "nodeSelectorTerms": [ + { + "matchExpressions": [ + { + "key": "extraRuntime", + "operator": "In", + "values": [ + "virtlet" + ] + } + ] + } + ] + } + } + }, + "containers": [ + { + "image": "virtlet.cloud/ubuntu/16.04:latest", + "imagePullPolicy": "IfNotPresent", + "name": "firewall", + "resources": { + "limits": { + "memory": "4Gi" + } + }, + "stdin": true, + "terminationMessagePath": "/dev/termination-log", + "terminationMessagePolicy": "File", + "tty": true + } + ], + "dnsPolicy": "ClusterFirst", + "restartPolicy": "Always", + "schedulerName": "default-scheduler", + "securityContext": {}, + "terminationGracePeriodSeconds": 30 + } + } + }, + "status": { + "conditions": [ + { + "lastTransitionTime": "2020-09-29T13:36:25Z", + "lastUpdateTime": "2020-09-29T13:36:25Z", + "message": "Deployment does not have minimum availability.", + "reason": "MinimumReplicasUnavailable", + "status": "False", + "type": "Available" + }, + { + "lastTransitionTime": "2020-09-29T13:36:25Z", + "lastUpdateTime": "2020-09-29T13:36:25Z", + "message": "ReplicaSet \"test-release-firewall-5bf9995f5f\" is progressing.", + "reason": "ReplicaSetUpdated", + "status": "True", + "type": "Progressing" + } + ], + "observedGeneration": 1, + "replicas": 1, + "unavailableReplicas": 1, + "updatedReplicas": 1 + } + } + }, + { + "name": "onap-private-net-test", + "GVK": { + "Group": "k8s.plugin.opnfv.org", + "Version": "v1alpha1", + "Kind": "Network" + }, + "status": { + "apiVersion": "k8s.plugin.opnfv.org/v1alpha1", + "kind": "Network", + "metadata": { + "creationTimestamp": "2020-09-29T13:36:25Z", + "finalizers": [ + "nfnCleanUpNetwork" + ], + "generation": 2, + "labels": { + "k8splugin.io/rb-instance-id": "practical_nobel" + }, + "name": "onap-private-net-test", + "namespace": "plugin-tests-namespace", + "resourceVersion": "10720825", + "selfLink": "/apis/k8s.plugin.opnfv.org/v1alpha1/namespaces/plugin-tests-namespace/networks/onap-private-net-test", + "uid": "43d413f1-f222-4d98-9ddd-b209d3ade106" + }, + "spec": { + "cniType": "ovn4nfv", + "dns": {}, + "ipv4Subnets": [ + { + "gateway": "10.10.0.1/16", + "name": "subnet1", + "subnet": "10.10.0.0/16" + } + ] + }, + "status": { + "state": "Created" + } + } + }, + { + "name": "protected-private-net", + "GVK": { + "Group": "k8s.plugin.opnfv.org", + "Version": "v1alpha1", + "Kind": "Network" + }, + "status": { + "apiVersion": "k8s.plugin.opnfv.org/v1alpha1", + "kind": "Network", + "metadata": { + "creationTimestamp": "2020-09-29T13:36:25Z", + "finalizers": [ + "nfnCleanUpNetwork" + ], + "generation": 2, + "labels": { + "k8splugin.io/rb-instance-id": "practical_nobel" + }, + "name": "protected-private-net", + "namespace": "plugin-tests-namespace", + "resourceVersion": "10720827", + "selfLink": "/apis/k8s.plugin.opnfv.org/v1alpha1/namespaces/plugin-tests-namespace/networks/protected-private-net", + "uid": "75c98944-80b6-4158-afed-8efa7a1075e2" + }, + "spec": { + "cniType": "ovn4nfv", + "dns": {}, + "ipv4Subnets": [ + { + "gateway": "192.168.20.100/24", + "name": "subnet1", + "subnet": "192.168.20.0/24" + } + ] + }, + "status": { + "state": "Created" + } + } + }, + { + "name": "unprotected-private-net", + "GVK": { + "Group": "k8s.plugin.opnfv.org", + "Version": "v1alpha1", + "Kind": "Network" + }, + "status": { + "apiVersion": "k8s.plugin.opnfv.org/v1alpha1", + "kind": "Network", + "metadata": { + "creationTimestamp": "2020-09-29T13:36:25Z", + "finalizers": [ + "nfnCleanUpNetwork" + ], + "generation": 2, + "labels": { + "k8splugin.io/rb-instance-id": "practical_nobel" + }, + "name": "unprotected-private-net", + "namespace": "plugin-tests-namespace", + "resourceVersion": "10720829", + "selfLink": "/apis/k8s.plugin.opnfv.org/v1alpha1/namespaces/plugin-tests-namespace/networks/unprotected-private-net", + "uid": "54995c10-bffd-4bb2-bbab-5de266af9456" + }, + "spec": { + "cniType": "ovn4nfv", + "dns": {}, + "ipv4Subnets": [ + { + "gateway": "192.168.10.1/24", + "name": "subnet1", + "subnet": "192.168.10.0/24" + } + ] + }, + "status": { + "state": "Created" + } + } + }, + { + "name": "test-release-firewall-5bf9995f5f-hnvps", + "GVK": { + "Group": "", + "Version": "", + "Kind": "" + }, + "status": { + "metadata": { + "annotations": { + "VirtletCloudInitUserData": "ssh_pwauth: True\nusers:\n- name: admin\n gecos: User\n primary-group: admin\n groups: users\n sudo: ALL=(ALL) NOPASSWD:ALL\n lock_passwd: false\n passwd: \"$6$rounds=4096$QA5OCKHTE41$jRACivoPMJcOjLRgxl3t.AMfU7LhCFwOWv2z66CQX.TSxBy50JoYtycJXSPr2JceG.8Tq/82QN9QYt3euYEZW/\"\nruncmd:\n - export demo_artifacts_version=1.5.0\n - export vfw_private_ip_0=192.168.10.3\n - export vsn_private_ip_0=192.168.20.3\n - export protected_net_cidr=192.168.20.0/24\n - export dcae_collector_ip=10.0.4.1\n - export dcae_collector_port=8081\n - export protected_net_gw=192.168.20.100/24\n - export protected_private_net_cidr=192.168.10.0/24\n - wget -O - https://git.onap.org/multicloud/k8s/plain/kud/tests/vFW/firewall | sudo -E bash\n", + "VirtletLibvirtCPUSetting": "mode: host-model\n", + "VirtletRootVolumeSize": "5Gi", + "k8s.plugin.opnfv.org/nfn-network": "{ \"type\": \"ovn4nfv\", \"interface\": [ { \"name\": \"unprotected-private-net\", \"ipAddress\": \"192.168.10.3\", \"interface\": \"eth1\" , \"defaultGateway\": \"false\"}, { \"name\": \"protected-private-net\", \"ipAddress\": \"192.168.20.2\", \"interface\": \"eth2\", \"defaultGateway\": \"false\" }, { \"name\": \"onap-private-net-test\", \"ipAddress\": \"10.10.100.3\", \"interface\": \"eth3\" , \"defaultGateway\": \"false\"} ]}", + "k8s.plugin.opnfv.org/ovnInterfaces": "[{\"ip_address\":\"192.168.10.3/24\", \"mac_address\":\"00:00:00:2b:62:71\", \"gateway_ip\": \"192.168.10.1\",\"defaultGateway\":\"false\",\"interface\":\"eth1\"},{\"ip_address\":\"192.168.20.2/24\", \"mac_address\":\"00:00:00:43:d6:f3\", \"gateway_ip\": \"192.168.20.100\",\"defaultGateway\":\"false\",\"interface\":\"eth2\"},{\"ip_address\":\"10.10.100.3/16\", \"mac_address\":\"00:00:00:03:4c:34\", \"gateway_ip\": \"10.10.0.1\",\"defaultGateway\":\"false\",\"interface\":\"eth3\"}]", + "k8s.v1.cni.cncf.io/networks": "[{\"name\": \"ovn-networkobj\", \"namespace\": \"default\"}]", + "k8s.v1.cni.cncf.io/networks-status": "[{\n \"name\": \"cni0\",\n \"interface\": \"virtlet-eth0\",\n \"ips\": [\n \"10.244.64.45\"\n ],\n \"mac\": \"0a:58:0a:f4:40:2d\",\n \"default\": true,\n \"dns\": {}\n},{\n \"name\": \"ovn4nfv-k8s-plugin\",\n \"interface\": \"eth3\",\n \"ips\": [\n \"192.168.10.3\",\n \"192.168.20.2\",\n \"10.10.100.3\"\n ],\n \"mac\": \"00:00:00:03:4c:34\",\n \"dns\": {}\n}]", + "kubernetes.io/target-runtime": "virtlet.cloud" + }, + "creationTimestamp": "2020-09-29T13:36:25Z", + "generateName": "test-release-firewall-5bf9995f5f-", + "labels": { + "app": "firewall", + "k8splugin.io/rb-instance-id": "practical_nobel", + "pod-template-hash": "5bf9995f5f", + "release": "test-release" + }, + "name": "test-release-firewall-5bf9995f5f-hnvps", + "namespace": "plugin-tests-namespace", + "ownerReferences": [ + { + "apiVersion": "apps/v1", + "blockOwnerDeletion": true, + "controller": true, + "kind": "ReplicaSet", + "name": "test-release-firewall-5bf9995f5f", + "uid": "8d68ff0c-c6f8-426c-8ebc-0ce5b7fb5132" + } + ], + "resourceVersion": "10720850", + "selfLink": "/api/v1/namespaces/plugin-tests-namespace/pods/test-release-firewall-5bf9995f5f-hnvps", + "uid": "92b169e3-2d25-449d-b029-d47674eb98e6" + }, + "spec": { + "affinity": { + "nodeAffinity": { + "requiredDuringSchedulingIgnoredDuringExecution": { + "nodeSelectorTerms": [ + { + "matchExpressions": [ + { + "key": "extraRuntime", + "operator": "In", + "values": [ + "virtlet" + ] + } + ] + } + ] + } + } + }, + "containers": [ + { + "image": "virtlet.cloud/ubuntu/16.04:latest", + "imagePullPolicy": "IfNotPresent", + "name": "firewall", + "resources": { + "limits": { + "memory": "4Gi" + }, + "requests": { + "memory": "4Gi" + } + }, + "stdin": true, + "terminationMessagePath": "/dev/termination-log", + "terminationMessagePolicy": "File", + "tty": true, + "volumeMounts": [ + { + "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount", + "name": "default-token-gsh95", + "readOnly": true + } + ] + } + ], + "dnsPolicy": "ClusterFirst", + "enableServiceLinks": true, + "nodeName": "localhost", + "priority": 0, + "restartPolicy": "Always", + "schedulerName": "default-scheduler", + "securityContext": {}, + "serviceAccount": "default", + "serviceAccountName": "default", + "terminationGracePeriodSeconds": 30, + "tolerations": [ + { + "effect": "NoExecute", + "key": "node.kubernetes.io/not-ready", + "operator": "Exists", + "tolerationSeconds": 300 + }, + { + "effect": "NoExecute", + "key": "node.kubernetes.io/unreachable", + "operator": "Exists", + "tolerationSeconds": 300 + } + ], + "volumes": [ + { + "name": "default-token-gsh95", + "secret": { + "defaultMode": 420, + "secretName": "default-token-gsh95" + } + } + ] + }, + "status": { + "conditions": [ + { + "lastProbeTime": null, + "lastTransitionTime": "2020-09-29T13:36:25Z", + "status": "True", + "type": "Initialized" + }, + { + "lastProbeTime": null, + "lastTransitionTime": "2020-09-29T13:36:25Z", + "message": "containers with unready status: [firewall]", + "reason": "ContainersNotReady", + "status": "False", + "type": "Ready" + }, + { + "lastProbeTime": null, + "lastTransitionTime": "2020-09-29T13:36:25Z", + "message": "containers with unready status: [firewall]", + "reason": "ContainersNotReady", + "status": "False", + "type": "ContainersReady" + }, + { + "lastProbeTime": null, + "lastTransitionTime": "2020-09-29T13:36:25Z", + "status": "True", + "type": "PodScheduled" + } + ], + "containerStatuses": [ + { + "image": "virtlet.cloud/ubuntu/16.04:latest", + "imageID": "", + "lastState": {}, + "name": "firewall", + "ready": false, + "restartCount": 0, + "state": { + "waiting": { + "reason": "ContainerCreating" + } + } + } + ], + "hostIP": "192.168.255.3", + "phase": "Pending", + "qosClass": "Burstable", + "startTime": "2020-09-29T13:36:25Z" + } + } + }, + { + "name": "test-release-packetgen-5647bfb56-ghpbs", + "GVK": { + "Group": "", + "Version": "", + "Kind": "" + }, + "status": { + "metadata": { + "annotations": { + "VirtletCloudInitUserData": "ssh_pwauth: True\nusers:\n- name: admin\n gecos: User\n primary-group: admin\n groups: users\n sudo: ALL=(ALL) NOPASSWD:ALL\n lock_passwd: false\n passwd: \"$6$rounds=4096$QA5OCKHTE41$jRACivoPMJcOjLRgxl3t.AMfU7LhCFwOWv2z66CQX.TSxBy50JoYtycJXSPr2JceG.8Tq/82QN9QYt3euYEZW/\"\nruncmd:\n - export demo_artifacts_version=1.5.0\n - export vfw_private_ip_0=192.168.10.3\n - export vsn_private_ip_0=192.168.20.3\n - export protected_net_cidr=192.168.20.0/24\n - export dcae_collector_ip=10.0.4.1\n - export dcae_collector_port=8081\n - export protected_net_gw=192.168.20.100/24\n - export protected_private_net_cidr=192.168.10.0/24\n - wget -O - https://git.onap.org/multicloud/k8s/plain/kud/tests/vFW/packetgen | sudo -E bash\n", + "VirtletLibvirtCPUSetting": "mode: host-model\n", + "VirtletRootVolumeSize": "5Gi", + "app": "packetgen", + "k8s.plugin.opnfv.org/nfn-network": "{ \"type\": \"ovn4nfv\", \"interface\":[ { \"name\": \"unprotected-private-net\", \"ipAddress\": \"192.168.10.2\", \"interface\": \"eth1\" , \"defaultGateway\": \"false\"}, { \"name\": \"onap-private-net-test\", \"ipAddress\": \"10.0.100.2\", \"interface\": \"eth2\" , \"defaultGateway\": \"false\"} ]}", + "k8s.plugin.opnfv.org/ovnInterfaces": "[{\"ip_address\":\"192.168.10.2/24\", \"mac_address\":\"00:00:00:ed:8c:d1\", \"gateway_ip\": \"192.168.10.1\",\"defaultGateway\":\"false\",\"interface\":\"eth1\"},{\"ip_address\":\"10.0.100.2/16\", \"mac_address\":\"00:00:00:97:31:3f\", \"gateway_ip\": \"10.10.0.1\",\"defaultGateway\":\"false\",\"interface\":\"eth2\"}]", + "k8s.v1.cni.cncf.io/networks": "[{\"name\": \"ovn-networkobj\", \"namespace\": \"default\"}]", + "k8s.v1.cni.cncf.io/networks-status": "[{\n \"name\": \"cni0\",\n \"interface\": \"virtlet-eth0\",\n \"ips\": [\n \"10.244.64.44\"\n ],\n \"mac\": \"0a:58:0a:f4:40:2c\",\n \"default\": true,\n \"dns\": {}\n},{\n \"name\": \"ovn4nfv-k8s-plugin\",\n \"interface\": \"eth2\",\n \"ips\": [\n \"192.168.10.2\",\n \"10.0.100.2\"\n ],\n \"mac\": \"00:00:00:97:31:3f\",\n \"dns\": {}\n}]", + "kubernetes.io/target-runtime": "virtlet.cloud", + "release": "test-release" + }, + "creationTimestamp": "2020-09-29T13:36:25Z", + "generateName": "test-release-packetgen-5647bfb56-", + "labels": { + "app": "packetgen", + "k8splugin.io/rb-instance-id": "practical_nobel", + "pod-template-hash": "5647bfb56", + "release": "test-release" + }, + "name": "test-release-packetgen-5647bfb56-ghpbs", + "namespace": "plugin-tests-namespace", + "ownerReferences": [ + { + "apiVersion": "apps/v1", + "blockOwnerDeletion": true, + "controller": true, + "kind": "ReplicaSet", + "name": "test-release-packetgen-5647bfb56", + "uid": "3c227839-04ad-4d16-b9ea-d8f436426de1" + } + ], + "resourceVersion": "10720852", + "selfLink": "/api/v1/namespaces/plugin-tests-namespace/pods/test-release-packetgen-5647bfb56-ghpbs", + "uid": "74aad8c5-b881-4881-b634-46ad48ccb857" + }, + "spec": { + "affinity": { + "nodeAffinity": { + "requiredDuringSchedulingIgnoredDuringExecution": { + "nodeSelectorTerms": [ + { + "matchExpressions": [ + { + "key": "extraRuntime", + "operator": "In", + "values": [ + "virtlet" + ] + } + ] + } + ] + } + } + }, + "containers": [ + { + "image": "virtlet.cloud/ubuntu/16.04:latest", + "imagePullPolicy": "IfNotPresent", + "name": "packetgen", + "resources": { + "limits": { + "memory": "4Gi" + }, + "requests": { + "memory": "4Gi" + } + }, + "stdin": true, + "terminationMessagePath": "/dev/termination-log", + "terminationMessagePolicy": "File", + "tty": true, + "volumeMounts": [ + { + "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount", + "name": "default-token-gsh95", + "readOnly": true + } + ] + } + ], + "dnsPolicy": "ClusterFirst", + "enableServiceLinks": true, + "nodeName": "localhost", + "priority": 0, + "restartPolicy": "Always", + "schedulerName": "default-scheduler", + "securityContext": {}, + "serviceAccount": "default", + "serviceAccountName": "default", + "terminationGracePeriodSeconds": 30, + "tolerations": [ + { + "effect": "NoExecute", + "key": "node.kubernetes.io/not-ready", + "operator": "Exists", + "tolerationSeconds": 300 + }, + { + "effect": "NoExecute", + "key": "node.kubernetes.io/unreachable", + "operator": "Exists", + "tolerationSeconds": 300 + } + ], + "volumes": [ + { + "name": "default-token-gsh95", + "secret": { + "defaultMode": 420, + "secretName": "default-token-gsh95" + } + } + ] + }, + "status": { + "conditions": [ + { + "lastProbeTime": null, + "lastTransitionTime": "2020-09-29T13:36:25Z", + "status": "True", + "type": "Initialized" + }, + { + "lastProbeTime": null, + "lastTransitionTime": "2020-09-29T13:36:25Z", + "message": "containers with unready status: [packetgen]", + "reason": "ContainersNotReady", + "status": "False", + "type": "Ready" + }, + { + "lastProbeTime": null, + "lastTransitionTime": "2020-09-29T13:36:25Z", + "message": "containers with unready status: [packetgen]", + "reason": "ContainersNotReady", + "status": "False", + "type": "ContainersReady" + }, + { + "lastProbeTime": null, + "lastTransitionTime": "2020-09-29T13:36:25Z", + "status": "True", + "type": "PodScheduled" + } + ], + "containerStatuses": [ + { + "image": "virtlet.cloud/ubuntu/16.04:latest", + "imageID": "", + "lastState": {}, + "name": "packetgen", + "ready": false, + "restartCount": 0, + "state": { + "waiting": { + "reason": "ContainerCreating" + } + } + } + ], + "hostIP": "192.168.255.3", + "phase": "Pending", + "qosClass": "Burstable", + "startTime": "2020-09-29T13:36:25Z" + } + } + }, + { + "name": "test-release-sink-6546c4f698-dv529", + "GVK": { + "Group": "", + "Version": "", + "Kind": "" + }, + "status": { + "metadata": { + "annotations": { + "k8s.plugin.opnfv.org/nfn-network": "{ \"type\": \"ovn4nfv\", \"interface\": [ { \"name\": \"protected-private-net\", \"ipAddress\": \"192.168.20.3\", \"interface\": \"eth1\", \"defaultGateway\": \"false\" }, { \"name\": \"onap-private-net-test\", \"ipAddress\": \"10.10.100.4\", \"interface\": \"eth2\" , \"defaultGateway\": \"false\"} ]}", + "k8s.plugin.opnfv.org/ovnInterfaces": "[{\"ip_address\":\"192.168.20.3/24\", \"mac_address\":\"00:00:00:13:40:87\", \"gateway_ip\": \"192.168.20.100\",\"defaultGateway\":\"false\",\"interface\":\"eth1\"},{\"ip_address\":\"10.10.100.4/16\", \"mac_address\":\"00:00:00:49:de:fc\", \"gateway_ip\": \"10.10.0.1\",\"defaultGateway\":\"false\",\"interface\":\"eth2\"}]", + "k8s.v1.cni.cncf.io/networks": "[{\"name\": \"ovn-networkobj\", \"namespace\": \"default\"}]", + "k8s.v1.cni.cncf.io/networks-status": "[{\n \"name\": \"cni0\",\n \"interface\": \"eth0\",\n \"ips\": [\n \"10.244.64.46\"\n ],\n \"mac\": \"0a:58:0a:f4:40:2e\",\n \"default\": true,\n \"dns\": {}\n},{\n \"name\": \"ovn4nfv-k8s-plugin\",\n \"interface\": \"eth2\",\n \"ips\": [\n \"192.168.20.3\",\n \"10.10.100.4\"\n ],\n \"mac\": \"00:00:00:49:de:fc\",\n \"dns\": {}\n}]" + }, + "creationTimestamp": "2020-09-29T13:36:25Z", + "generateName": "test-release-sink-6546c4f698-", + "labels": { + "app": "sink", + "k8splugin.io/rb-instance-id": "practical_nobel", + "pod-template-hash": "6546c4f698", + "release": "test-release" + }, + "name": "test-release-sink-6546c4f698-dv529", + "namespace": "plugin-tests-namespace", + "ownerReferences": [ + { + "apiVersion": "apps/v1", + "blockOwnerDeletion": true, + "controller": true, + "kind": "ReplicaSet", + "name": "test-release-sink-6546c4f698", + "uid": "72c9da29-af3b-4b5c-a90b-06285ae83429" + } + ], + "resourceVersion": "10720854", + "selfLink": "/api/v1/namespaces/plugin-tests-namespace/pods/test-release-sink-6546c4f698-dv529", + "uid": "a4e24041-65c9-4b86-8f10-a27a4dba26bb" + }, + "spec": { + "containers": [ + { + "envFrom": [ + { + "configMapRef": { + "name": "sink-configmap" + } + } + ], + "image": "rtsood/onap-vfw-demo-sink:0.2.0", + "imagePullPolicy": "IfNotPresent", + "name": "sink", + "resources": {}, + "securityContext": { + "privileged": true + }, + "stdin": true, + "terminationMessagePath": "/dev/termination-log", + "terminationMessagePolicy": "File", + "tty": true, + "volumeMounts": [ + { + "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount", + "name": "default-token-gsh95", + "readOnly": true + } + ] + }, + { + "image": "electrocucaracha/darkstat:latest", + "imagePullPolicy": "IfNotPresent", + "name": "darkstat", + "ports": [ + { + "containerPort": 667, + "protocol": "TCP" + } + ], + "resources": {}, + "stdin": true, + "terminationMessagePath": "/dev/termination-log", + "terminationMessagePolicy": "File", + "tty": true, + "volumeMounts": [ + { + "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount", + "name": "default-token-gsh95", + "readOnly": true + } + ] + } + ], + "dnsPolicy": "ClusterFirst", + "enableServiceLinks": true, + "nodeName": "localhost", + "priority": 0, + "restartPolicy": "Always", + "schedulerName": "default-scheduler", + "securityContext": {}, + "serviceAccount": "default", + "serviceAccountName": "default", + "terminationGracePeriodSeconds": 30, + "tolerations": [ + { + "effect": "NoExecute", + "key": "node.kubernetes.io/not-ready", + "operator": "Exists", + "tolerationSeconds": 300 + }, + { + "effect": "NoExecute", + "key": "node.kubernetes.io/unreachable", + "operator": "Exists", + "tolerationSeconds": 300 + } + ], + "volumes": [ + { + "name": "default-token-gsh95", + "secret": { + "defaultMode": 420, + "secretName": "default-token-gsh95" + } + } + ] + }, + "status": { + "conditions": [ + { + "lastProbeTime": null, + "lastTransitionTime": "2020-09-29T13:36:25Z", + "status": "True", + "type": "Initialized" + }, + { + "lastProbeTime": null, + "lastTransitionTime": "2020-09-29T13:36:33Z", + "status": "True", + "type": "Ready" + }, + { + "lastProbeTime": null, + "lastTransitionTime": "2020-09-29T13:36:33Z", + "status": "True", + "type": "ContainersReady" + }, + { + "lastProbeTime": null, + "lastTransitionTime": "2020-09-29T13:36:25Z", + "status": "True", + "type": "PodScheduled" + } + ], + "containerStatuses": [ + { + "containerID": "docker://87c9af78735400606d70ccd9cd85e2545e43cb3be9c30d4b4fe173da0062dda9", + "image": "electrocucaracha/darkstat:latest", + "imageID": "docker-pullable://electrocucaracha/darkstat@sha256:a6764fcc2e15f6156ac0e56f1d220b98970f2d4da9005bae99fb518cfd2f9c25", + "lastState": {}, + "name": "darkstat", + "ready": true, + "restartCount": 0, + "started": true, + "state": { + "running": { + "startedAt": "2020-09-29T13:36:33Z" + } + } + }, + { + "containerID": "docker://a004f95e7c7a681c7f400852aade096e3ffd75b7efc64e12e65b4ce1fe326577", + "image": "rtsood/onap-vfw-demo-sink:0.2.0", + "imageID": "docker-pullable://rtsood/onap-vfw-demo-sink@sha256:15b7abb0b67a3804ea5f954254633f996fc99c680b09d86a6cf15c3d7b14ab16", + "lastState": {}, + "name": "sink", + "ready": true, + "restartCount": 0, + "started": true, + "state": { + "running": { + "startedAt": "2020-09-29T13:36:32Z" + } + } + } + ], + "hostIP": "192.168.255.3", + "phase": "Running", + "podIP": "10.244.64.46", + "podIPs": [ + { + "ip": "10.244.64.46" + } + ], + "qosClass": "BestEffort", + "startTime": "2020-09-29T13:36:25Z" + } + } + } + ] +} diff --git a/docs/files/vFW_CNF_CDS/vfw-generic-vnf-aai.json b/docs/files/vFW_CNF_CDS/vfw-generic-vnf-aai.json new file mode 100644 index 000000000..89b7f7a2d --- /dev/null +++ b/docs/files/vFW_CNF_CDS/vfw-generic-vnf-aai.json @@ -0,0 +1,167 @@ +{ + "vnf-id": "d4af22f0-70e6-47ac-8d5b-4d645fc25757", + "vnf-name": "VF_vfw_k8s_demo_CNF_LR_1", + "vnf-type": "vfw_k8s_demo_CNF_LR_1/null", + "service-id": "vfw_k8s_demo_CNF_LR_1", + "prov-status": "NVTPROV", + "orchestration-status": "Active", + "in-maint": false, + "is-closed-loop-disabled": false, + "resource-version": "1635943409675", + "model-invariant-id": "a5c188d5-7f0a-44e9-bd92-4a60781cb2cf", + "model-version-id": "033d9730-549a-4ff8-b166-1581fb73aa08", + "model-customization-id": "f107d24c-0a2f-4eb9-96d3-7a631c973cfd", + "relationship-list": { + "relationship": [ + { + "related-to": "tenant", + "relationship-label": "org.onap.relationships.inventory.BelongsTo", + "related-link": "/aai/v21/cloud-infrastructure/cloud-regions/cloud-region/K8sCloudOwner/kud-lr/tenants/tenant/3444a566-2717-4d85-83bd-45c104657173", + "relationship-data": [ + { + "relationship-key": "cloud-region.cloud-owner", + "relationship-value": "K8sCloudOwner" + }, + { + "relationship-key": "cloud-region.cloud-region-id", + "relationship-value": "kud-lr" + }, + { + "relationship-key": "tenant.tenant-id", + "relationship-value": "3444a566-2717-4d85-83bd-45c104657173" + } + ], + "related-to-property": [ + { + "property-key": "tenant.tenant-name", + "property-value": "kud-lr-tenant" + } + ] + }, + { + "related-to": "cloud-region", + "relationship-label": "org.onap.relationships.inventory.LocatedIn", + "related-link": "/aai/v21/cloud-infrastructure/cloud-regions/cloud-region/K8sCloudOwner/kud-lr", + "relationship-data": [ + { + "relationship-key": "cloud-region.cloud-owner", + "relationship-value": "K8sCloudOwner" + }, + { + "relationship-key": "cloud-region.cloud-region-id", + "relationship-value": "kud-lr" + } + ], + "related-to-property": [ + { + "property-key": "cloud-region.owner-defined-type", + "property-value": "t1" + } + ] + }, + { + "related-to": "service-instance", + "relationship-label": "org.onap.relationships.inventory.ComposedOf", + "related-link": "/aai/v21/business/customers/customer/customer_cnf/service-subscriptions/service-subscription/vfw_k8s_demo_CNF_LR_1/service-instances/service-instance/93b89241-104b-40a7-8030-32e3b6eff459", + "relationship-data": [ + { + "relationship-key": "customer.global-customer-id", + "relationship-value": "customer_cnf" + }, + { + "relationship-key": "service-subscription.service-type", + "relationship-value": "vfw_k8s_demo_CNF_LR_1" + }, + { + "relationship-key": "service-instance.service-instance-id", + "relationship-value": "93b89241-104b-40a7-8030-32e3b6eff459" + } + ], + "related-to-property": [ + { + "property-key": "service-instance.service-instance-name", + "property-value": "INSTANCE_vfw_k8s_demo_CNF_LR_1" + } + ] + }, + { + "related-to": "platform", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v21/business/platforms/platform/%3Conapsdk.vid.vid.Platform%20object%20at%200x7f48eddc2c40%3E", + "relationship-data": [ + { + "relationship-key": "platform.platform-name", + "relationship-value": "<onapsdk.vid.vid.Platform object at 0x7f48eddc2c40>" + } + ] + }, + { + "related-to": "line-of-business", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v21/business/lines-of-business/line-of-business/%3Conapsdk.vid.vid.LineOfBusiness%20object%20at%200x7f48eddc2040%3E", + "relationship-data": [ + { + "relationship-key": "line-of-business.line-of-business-name", + "relationship-value": "<onapsdk.vid.vid.LineOfBusiness object at 0x7f48eddc2040>" + } + ] + } + ] + }, + "vf-modules": { + "vf-module": [ + { + "vf-module-id": "abb282c8-c932-45dc-9c62-01938eab32fa", + "vf-module-name": "INSTANCE_vfw_k8s_demo_CNF_LR_1_vf_vfw_k8s_demo_cnf_lr_10..VfVfwK8sDemoCnfLr1..helm_base_template..module-4", + "heat-stack-id": "nifty_lichterman", + "orchestration-status": "Active", + "is-base-vf-module": false, + "automated-assignment": false, + "resource-version": "1635943380124", + "model-invariant-id": "7b0bcafb-6437-461c-bb48-7240f67ee718", + "model-version-id": "5cc1eda3-24e2-4e5e-a4a0-cb18477834f6", + "model-customization-id": "b80dedcd-902e-4c75-939a-310a68acb440", + "module-index": 0 + }, + { + "vf-module-id": "314795d7-6005-4462-a9fe-7006538e3ff9", + "vf-module-name": "INSTANCE_vfw_k8s_demo_CNF_LR_1_vf_vfw_k8s_demo_cnf_lr_10..VfVfwK8sDemoCnfLr1..helm_vpkg..module-2", + "heat-stack-id": "dazzling_nightingale", + "orchestration-status": "Active", + "is-base-vf-module": false, + "automated-assignment": false, + "resource-version": "1635943396304", + "model-invariant-id": "8f3652a6-af23-4d8c-9aa2-3e8d6f1a5b6e", + "model-version-id": "f4e54571-7cc7-4a67-b973-1851b8e540a7", + "model-customization-id": "5f1445b0-9ef2-4eb3-8051-a445fa35f877", + "module-index": 0 + }, + { + "vf-module-id": "56f3d02b-5a32-4a97-9e7b-d3c0094c07e8", + "vf-module-name": "INSTANCE_vfw_k8s_demo_CNF_LR_1_vf_vfw_k8s_demo_cnf_lr_10..VfVfwK8sDemoCnfLr1..helm_vsn..module-1", + "heat-stack-id": "sharp_torvalds", + "orchestration-status": "Active", + "is-base-vf-module": false, + "automated-assignment": false, + "resource-version": "1635943404667", + "model-invariant-id": "46a8e556-6c5f-4acd-9cfc-ea29b51c919e", + "model-version-id": "aa1ecbc5-990e-4ed0-a03e-a135f21763d3", + "model-customization-id": "0e61ce72-5eef-4fd7-b790-2107b67044f6", + "module-index": 0 + }, + { + "vf-module-id": "d56c54b9-40cc-4b7a-abce-50454571e39d", + "vf-module-name": "INSTANCE_vfw_k8s_demo_CNF_LR_1_vf_vfw_k8s_demo_cnf_lr_10..VfVfwK8sDemoCnfLr1..helm_vfw..module-3", + "heat-stack-id": "brave_brattain", + "orchestration-status": "Active", + "is-base-vf-module": false, + "automated-assignment": false, + "resource-version": "1635943387739", + "model-invariant-id": "89f47572-1d25-44b4-a6e0-52d0421a0980", + "model-version-id": "12a89df1-9fad-4045-a90e-dcb64264eed4", + "model-customization-id": "c81f3c71-3f42-4831-b3b2-7ceffb567795", + "module-index": 0 + } + ] + } +} diff --git a/docs/files/vFW_CNF_CDS/vpkg-vf-module-aai.json b/docs/files/vFW_CNF_CDS/vpkg-vf-module-aai.json new file mode 100644 index 000000000..84d62ca6c --- /dev/null +++ b/docs/files/vFW_CNF_CDS/vpkg-vf-module-aai.json @@ -0,0 +1,133 @@ +{ + "vf-module-id": "314795d7-6005-4462-a9fe-7006538e3ff9", + "vf-module-name": "INSTANCE_vfw_k8s_demo_CNF_LR_1_vf_vfw_k8s_demo_cnf_lr_10..VfVfwK8sDemoCnfLr1..helm_vpkg..module-2", + "heat-stack-id": "dazzling_nightingale", + "orchestration-status": "Active", + "is-base-vf-module": false, + "automated-assignment": false, + "resource-version": "1635943396304", + "model-invariant-id": "8f3652a6-af23-4d8c-9aa2-3e8d6f1a5b6e", + "model-version-id": "f4e54571-7cc7-4a67-b973-1851b8e540a7", + "model-customization-id": "5f1445b0-9ef2-4eb3-8051-a445fa35f877", + "module-index": 0, + "relationship-list": { + "relationship": [ + { + "related-to": "k8s-resource", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/cloud-infrastructure/cloud-regions/cloud-region/K8sCloudOwner/kud-lr/tenants/tenant/3444a566-2717-4d85-83bd-45c104657173/k8s-resources/k8s-resource/e73732351195c8c10d28413ddff1d968bd53b0b0e395c24b3b0fcd39f46ea730", + "relationship-data": [ + { + "relationship-key": "cloud-region.cloud-owner", + "relationship-value": "K8sCloudOwner" + }, + { + "relationship-key": "cloud-region.cloud-region-id", + "relationship-value": "kud-lr" + }, + { + "relationship-key": "tenant.tenant-id", + "relationship-value": "3444a566-2717-4d85-83bd-45c104657173" + }, + { + "relationship-key": "k8s-resource.id", + "relationship-value": "e73732351195c8c10d28413ddff1d968bd53b0b0e395c24b3b0fcd39f46ea730" + } + ], + "related-to-property": [ + { + "property-key": "k8s-resource.name", + "property-value": "vfw-1-vpkg-mgmt" + } + ] + }, + { + "related-to": "k8s-resource", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/cloud-infrastructure/cloud-regions/cloud-region/K8sCloudOwner/kud-lr/tenants/tenant/3444a566-2717-4d85-83bd-45c104657173/k8s-resources/k8s-resource/f65235da9cb098588b2db0c9e7da1ccb00954268fba6bd621bb9ef0b48cd717f", + "relationship-data": [ + { + "relationship-key": "cloud-region.cloud-owner", + "relationship-value": "K8sCloudOwner" + }, + { + "relationship-key": "cloud-region.cloud-region-id", + "relationship-value": "kud-lr" + }, + { + "relationship-key": "tenant.tenant-id", + "relationship-value": "3444a566-2717-4d85-83bd-45c104657173" + }, + { + "relationship-key": "k8s-resource.id", + "relationship-value": "f65235da9cb098588b2db0c9e7da1ccb00954268fba6bd621bb9ef0b48cd717f" + } + ], + "related-to-property": [ + { + "property-key": "k8s-resource.name", + "property-value": "vfw-1-vpkg" + } + ] + }, + { + "related-to": "k8s-resource", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/cloud-infrastructure/cloud-regions/cloud-region/K8sCloudOwner/kud-lr/tenants/tenant/3444a566-2717-4d85-83bd-45c104657173/k8s-resources/k8s-resource/87cbdb83bf436703bdb9823e07e1498a7b3ec7fb12ba14193aadd4630649e0ae", + "relationship-data": [ + { + "relationship-key": "cloud-region.cloud-owner", + "relationship-value": "K8sCloudOwner" + }, + { + "relationship-key": "cloud-region.cloud-region-id", + "relationship-value": "kud-lr" + }, + { + "relationship-key": "tenant.tenant-id", + "relationship-value": "3444a566-2717-4d85-83bd-45c104657173" + }, + { + "relationship-key": "k8s-resource.id", + "relationship-value": "87cbdb83bf436703bdb9823e07e1498a7b3ec7fb12ba14193aadd4630649e0ae" + } + ], + "related-to-property": [ + { + "property-key": "k8s-resource.name", + "property-value": "vfw-1-vpkg-c6bdb954c-mlpz9" + } + ] + }, + { + "related-to": "k8s-resource", + "relationship-label": "org.onap.relationships.inventory.Uses", + "related-link": "/aai/v24/cloud-infrastructure/cloud-regions/cloud-region/K8sCloudOwner/kud-lr/tenants/tenant/3444a566-2717-4d85-83bd-45c104657173/k8s-resources/k8s-resource/5538b19871da1fd05b82366c38cbbe88bae4d3444b6a21018f83787327958617", + "relationship-data": [ + { + "relationship-key": "cloud-region.cloud-owner", + "relationship-value": "K8sCloudOwner" + }, + { + "relationship-key": "cloud-region.cloud-region-id", + "relationship-value": "kud-lr" + }, + { + "relationship-key": "tenant.tenant-id", + "relationship-value": "3444a566-2717-4d85-83bd-45c104657173" + }, + { + "relationship-key": "k8s-resource.id", + "relationship-value": "5538b19871da1fd05b82366c38cbbe88bae4d3444b6a21018f83787327958617" + } + ], + "related-to-property": [ + { + "property-key": "k8s-resource.name", + "property-value": "vfw-1-vpkg-configmap" + } + ] + } + ] + } +} diff --git a/docs/files/windriver/windriver_CPU.png b/docs/files/windriver/windriver_CPU.png Binary files differnew file mode 100644 index 000000000..abf334b81 --- /dev/null +++ b/docs/files/windriver/windriver_CPU.png diff --git a/docs/files/windriver/windriver_RAM.png b/docs/files/windriver/windriver_RAM.png Binary files differnew file mode 100644 index 000000000..1333f01cb --- /dev/null +++ b/docs/files/windriver/windriver_RAM.png diff --git a/docs/files/windriver/windriver_disks.png b/docs/files/windriver/windriver_disks.png Binary files differnew file mode 100644 index 000000000..1f7fc5265 --- /dev/null +++ b/docs/files/windriver/windriver_disks.png diff --git a/docs/files/windriver/windriver_servers.png b/docs/files/windriver/windriver_servers.png Binary files differnew file mode 100644 index 000000000..39671782f --- /dev/null +++ b/docs/files/windriver/windriver_servers.png diff --git a/docs/files/windriver/windrivers_servers2.png b/docs/files/windriver/windrivers_servers2.png Binary files differnew file mode 100644 index 000000000..90d63c35a --- /dev/null +++ b/docs/files/windriver/windrivers_servers2.png diff --git a/docs/functional-requirements-5g.csv b/docs/functional-requirements-5g.csv deleted file mode 100644 index 286fd3aba..000000000 --- a/docs/functional-requirements-5g.csv +++ /dev/null @@ -1,11 +0,0 @@ -5G functional requirement,Link,Contacts -5G Realtime PM and High Volume Stream Data Collection, :ref:`official doc <docs_realtime_pm>`,M.Przybysz -5G PNF Plug and Play, :ref:`official doc <docs_5g_pnf_pnp>`, M.Przybysz K.Kuzmicki -5G Bulk PM, :ref:`official doc <docs_5g_bulk_pm>`, J.Cuddy -5G OOF and PCI,:ref:`official doc <docs_5G_oof_pci>`, Reshmasree c -5G NRM Network Resource Model (Configuration management),:ref:`official doc <docs_5G_NRM_Configuration>`,Y.Wang C.Huang -5G NETCONF configuration,:ref:`official doc <docs_5G_Configuration_over_NETCONF>`, A.D.Singh -5G PNF Pre-Onboarding & Onboarding,:ref:`official doc <docs_pnf_onboarding_preonboarding>`,M.Przybysz K.Kuzmicki D.Melia A.Walshe -5G OOF SON,:ref:`official doc <docs_5G_oof_pci>`,Reshmasree c -5G E2E Network Slicing ,:ref:`official doc<docs_E2E_network_slicing>`,C.Chen Z.Min Swaminathan S -5G ORAN A1 Adapter (SDNR),:ref:`official doc <docs_5g_a1_adaptor>`,SandeepShah diff --git a/docs/functional-requirements.csv b/docs/functional-requirements.csv deleted file mode 100644 index 5e75fb510..000000000 --- a/docs/functional-requirements.csv +++ /dev/null @@ -1,11 +0,0 @@ -Functional requirement,Link,Contacts -PNF Software Upgrade using direct Netconf Yang interface with PNF,:ref:`official doc <docs_5g_pnf_software_upgrade>`,R.Gumma R.Tyagi -PNF Software Upgrade with EM with Ansible,:ref:`official doc <docs_5G_PNF_Software_Upgrade_ansible_with_EM>`, Y.Wang E.Wang -PNF Software Upgrade with EM with Netconf, :ref:`official doc <docs_5g_pnf_software_upgrade_netconf_with_EM>`, Y.Wang E.Wang -VSP Compliance and Validation Check within SDC,`wiki page <https://wiki.onap.org/display/DW/VSP+Compliance+and+Validation+Check+within+SDC+%28Frankfurt%29+-+Phase+2#VSPComplianceandValidationCheckwithinSDC(Frankfurt)Phase2-VSPComplianceCheckwithinSDC-IntegrationTestPlan>`__,P.Balan -Enable PNF software version at onboarding,`wiki page <https://jira.onap.org/browse/REQ-88?src=confmacro>`__,A.Schmid -xNF communication security enhancements, `wiki page <https://wiki.onap.org/display/DW/xNF+communication+security+enhancements+-+Tests+Description+and+Status>`__,M.Przybysz -ETSI Alignment SO plugin to support SOL003 to connect to an external VNFM,`wiki page <https://wiki.onap.org/display/DW/ETSI+Alignment+Support>`__,F.Oliveira Byung-Woo Jun -Integration of CDS as an Actor, `wiki page <https://docs.onap.org/en/latest/submodules/policy/parent.git/docs/development/actors/cds/cds.html>`__, B.Sakoto R.K.Verma Y.Malakov -3rd Party Operational Domain Manager, `wiki page <https://wiki.onap.org/display/DW/Third-party+Operational+Domain+Manager>`__, D.Patel -Configuration & persistency, `wiki page <https://wiki.onap.org/pages/viewpage.action?pageId=64003184>`__,Reshmasree c Swaminathan S diff --git a/docs/heat.rst b/docs/heat.rst deleted file mode 100644 index cb34c87cc..000000000 --- a/docs/heat.rst +++ /dev/null @@ -1,237 +0,0 @@ -ONAP HEAT Template ------------------- - -Source files -~~~~~~~~~~~~ - -- Template file: https://git.onap.org/integration/plain/deployment/heat/onap-rke/onap-oom.yaml -- Environment file: https://git.onap.org/integration/plain/deployment/heat/onap-rke/env/windriver/onap-oom.env - -The files are based on the windriver environement used by the integration team. - -Description -~~~~~~~~~~~ - -The ONAP HEAT template spins up the entire ONAP platform. The template, -onap_openstack.yaml, comes with an environment file, -onap_openstack.env, in which all the default values are defined. - -.. note:: - onap_openstack.yaml AND onap_openstack.env ARE THE HEAT TEMPLATE - AND ENVIRONMENT FILE CURRENTLY SUPPORTED. - onap_openstack_float.yaml/env AND onap_openstack_nofloat.yaml/env - AREN'T UPDATED AND THEIR USAGE IS NOT SUGGESTED. - -The HEAT template is composed of two sections: (i) parameters, and (ii) -resources. -The parameter section contains the declaration and -description of the parameters that will be used to spin up ONAP, such as -public network identifier, URLs of code and artifacts repositories, etc. -The default values of these parameters can be found in the environment -file. - -The resource section contains the definition of: - -- ONAP Private Management Network, which ONAP components use to communicate with each other and with VNFs -- ONAP Virtual Machines (VMs) -- Public/private key pair used to access ONAP VMs -- Virtual interfaces towards the ONAP Private Management Network -- Disk volumes. - -Each VM specification includes Operating System image name, VM size -(i.e. flavor), VM name, etc. Each VM has two virtual network interfaces: -one towards the public network and one towards the ONAP Private -Management network, as described above. Furthermore, each VM runs a -post-instantiation script that downloads and installs software -dependencies (e.g. Java JDK, gcc, make, Python, ...) and ONAP software -packages and docker containers from remote repositories. - -When the HEAT template is executed, the Openstack HEAT engine creates -the resources defined in the HEAT template, based on the parameters -values defined in the environment file. - -Environment file -~~~~~~~~~~~~~~~~ - -Before running HEAT, it is necessary to customize the environment file. -Indeed, some parameters, namely public_net_id, pub_key, -openstack_tenant_id, openstack_username, and openstack_api_key, -need to be set depending on the user's environment: - -**Global parameters** - -:: - - public_net_id: PUT YOUR NETWORK ID/NAME HERE - pub_key: PUT YOUR PUBLIC KEY HERE - openstack_tenant_id: PUT YOUR OPENSTACK PROJECT ID HERE - openstack_username: PUT YOUR OPENSTACK USERNAME HERE - openstack_api_key: PUT YOUR OPENSTACK PASSWORD HERE - horizon_url: PUT THE HORIZON URL HERE - keystone_url: PUT THE KEYSTONE URL HERE (do not include version number) - -openstack_region parameter is set to RegionOne (OpenStack default). If -your OpenStack is using another Region, please modify this parameter. - -public_net_id is the unique identifier (UUID) or name of the public -network of the cloud provider. To get the public_net_id, use the -following OpenStack CLI command (ext is the name of the external -network, change it with the name of the external network of your -installation) - -:: - - openstack network list | grep ext | awk '{print $2}' - -pub_key is string value of the public key that will be installed in -each ONAP VM. To create a public/private key pair in Linux, please -execute the following instruction: - -:: - - user@ubuntu:~$ ssh-keygen -t rsa - -The following operations to create the public/private key pair occur: - -:: - - Generating public/private rsa key pair. - Enter file in which to save the key (/home/user/.ssh/id_rsa): - Created directory '/home/user/.ssh'. - Enter passphrase (empty for no passphrase): - Enter same passphrase again: - Your identification has been saved in /home/user/.ssh/id_rsa. - Your public key has been saved in /home/user/.ssh/id_rsa.pub. - -openstack_username, openstack_tenant_id (password), and -openstack_api_key are user's credentials to access the -OpenStack-based cloud. - -**Images and flavors parameters** - -:: - - ubuntu_1404_image: PUT THE UBUNTU 14.04 IMAGE NAME HERE - ubuntu_1604_image: PUT THE UBUNTU 16.04 IMAGE NAME HERE - flavor_small: PUT THE SMALL FLAVOR NAME HERE - flavor_medium: PUT THE MEDIUM FLAVOR NAME HERE - flavor_large: PUT THE LARGE FLAVOR NAME HERE - flavor_xlarge: PUT THE XLARGE FLAVOR NAME HERE - flavor_xxlarge: PUT THE XXLARGE FLAVOR NAME HERE - -To get the images in your OpenStack environment, use the following -OpenStack CLI command: - -:: - - openstack image list | grep 'ubuntu' - -To get the flavor names used in your OpenStack environment, use the -following OpenStack CLI command: - -:: - - openstack flavor list - -**DNS parameters** - -:: - - dns_list: PUT THE ADDRESS OFTHE EXTERNAL DNS HERE (e.g. a comma-separated list of IP addresses in your /etc/resolv.conf in UNIX-based Operating Systems). THIS LIST MUST INCLUDE THE DNS SERVER THAT OFFERS DNS AS AS SERVICE (see DCAE section below for more details) - external_dns: PUT THE FIRST ADDRESS OF THE EXTERNAL DNS LIST HERE oam_network_cidr: 10.0.0.0/16 - -You can use the Google Public DNS 8.8.8.8 and 4.4.4.4 address or your internal DNS servers - -**DCAE Parameters** - -DCAE spins up ONAP's data collection and analytics system in two phases. -The first is the launching of a bootstrap VM that is specified in the -ONAP Heat template. This VM requires a number of deployment specific -conifiguration parameters being provided so that it can subsequently -bring up the DCAE system. There are two groups of parameters. - -The first group relates to the launching of DCAE VMs, including parameters such as -the keystone URL and additional VM image IDs/names. DCAE VMs are -connected to the same internal network as the rest of ONAP VMs, but -dynamically spun up by the DCAE core platform. Hence these parameters -need to be provided to DCAE. Note that although DCAE VMs will be -launched in the same tenant as the rest of ONAP, because DCAE may use -MultiCloud node as the agent for interfacing with the underying cloud, -it needs a separate keystone URL (which points to MultiCloud node -instead of the underlying cloud). - -The second group of configuration parameters relate to DNS As A Service support (DNSaaS). -DCAE requires DNSaaS for registering its VMs into organization-wide DNS service. For -OpenStack, DNSaaS is provided by Designate. Designate support can be -provided via an integrated service endpoint listed under the service -catalog of the OpenStack installation; or proxyed by the ONAP MultiCloud -service. For the latter case, a number of parameters are needed to -configure MultiCloud to use the correct Designate service. These -parameters are described below: - -:: - - dcae_keystone_url: PUT THE KEYSTONE URL OF THE OPENSTACK INSTANCE WHERE DCAE IS DEPLOYED (Note: put the MultiCloud proxy URL if the DNSaaS is proxyed by MultiCloud) - dcae_centos_7_image: PUT THE CENTOS7 IMAGE ID/NAME AVAILABLE AT THE OPENSTACK INSTANCE WHERE DCAE IS DEPLOYED - dcae_security_group: PUT THE SECURITY GROUP ID/NAME TO BE USED AT THE OPENSTACK INSTANCE WHERE DCAE IS DEPLOYED - dcae_key_name: PUT THE ACCESS KEY-PAIR NAME REGISTER AT THE OPENSTACK INSTANCE WHERE DCAE IS DEPLOYED - dcae_public_key: PUT THE PUBLIC KEY OF A KEY-PAIR USED FOR DCAE BOOTSTRAP NODE TO COMMUNICATE WITH DCAE VMS - dcae_private_key: PUT THE PRIVATE KEY OF A KEY-PAIR USED FOR DCAE BOOTSTRAP NODE TO COMMUNICATE WITH DCAE VMS - - dnsaas_config_enabled: true or false FOR WHETHER DNSAAS IS PROXYED - dnsaas_region: PUT THE REGION OF THE OPENSTACK INSTANCE WHERE DNSAAS IS PROVIDED - dnsaas_tenant_id: PUT THE TENANT ID/NAME OF THE OPENSTACK INSTANCE WHERE DNSAAS IS PROVIDED - dnsaas_keystone_url: PUT THE KEYSTONE URL OF THE OPENSTACK INSTANCE WHERE DNSAAS IS PROVIDED - dnsaas_username: PUT THE USERNAME OF THE OPENSTACK INSTANCE WHERE DNSAAS IS PROVIDED - dnsaas_password: PUT THE PASSWORD OF THE OPENSTACK INSTANCE WHERE DNSAAS IS PROVIDED - -Instantiation -~~~~~~~~~~~~~ - -The ONAP platform can be instantiated via Horizon (OpenStack dashboard) -or Command Line. - -**Instantiation via Horizon:** - -- Login to Horizon URL with your personal credentials -- Click "Stacks" from the "Orchestration" menu -- Click "Launch Stack" -- Paste or manually upload the HEAT template file (onap_openstack.yaml) in the "Template Source" form -- Paste or manually upload the HEAT environment file (onap_openstack.env) in the "Environment Source" form -- Click "Next" - Specify a name in the "Stack Name" form -- Provide the password in the "Password" form -- Click "Launch" - -**Instantiation via Command Line:** - -- Install the HEAT client on your machine, e.g. in Ubuntu (ref. http://docs.openstack.org/user-guide/common/cli-install-openstack-command-line-clients.html): - -:: - - apt-get install python-dev python-pip - pip install python-heatclient # Install heat client - pip install python-openstackclient # Install the Openstack client to support multiple services - -- Create a file (named i.e. ~/openstack/openrc) that sets all the - environmental variables required to access Rackspace: - -:: - - export OS_AUTH_URL=INSERT THE AUTH URL HERE - export OS_USERNAME=INSERT YOUR USERNAME HERE - export OS_TENANT_ID=INSERT YOUR TENANT ID HERE - export OS_REGION_NAME=INSERT THE REGION HERE - export OS_PASSWORD=INSERT YOUR PASSWORD HERE - -- Run the script from command line: - -:: - - source ~/openstack/openrc - -- In order to install the ONAP platform, type: - -:: - - heat stack-create STACK_NAME -f PATH_TO_HEAT_TEMPLATE(YAML FILE) -e PATH_TO_ENV_FILE # Old HEAT client, OR - openstack stack create -t PATH_TO_HEAT_TEMPLATE(YAML FILE) -e PATH_TO_ENV_FILE STACK_NAME # New Openstack client diff --git a/docs/index.rst b/docs/index.rst index c6bbd7109..eb10f12a8 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -1,62 +1,13 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 .. _master_index: INTEGRATION =========== -The Integration project is in charge of: +.. toctree:: + :maxdepth: 1 -- Providing testing environment and support for the release use cases -- Executing Cross-project Continuous System Integration Testing (CSIT) -- Managing full ONAP CI chains (daily master, staging, stable) to ensure the - stability of the integration -- Developing and performing tests within full ONAP context (healthcheck, End to - End, performance, robustness...) -- Validating the ONAP release - -For each release, the integration team provides the following artifacts: - -- Test suites and tools to check the various ONAP components -- Use-case documentation and artifacts -- a testsuite docker included in ONAP cluster to execute the tests -- baseline JAVA and Python images, as well as a docker managing Java libraries -- Configuration fiales and Heat templates to simplify the creation of the virtual - ressources needed for the ONAP deployment and the use cases. - -The integration team manages several official ONAP repositories: - -.. csv-table:: Integration repositories table - :file: integration-repositories.csv - :widths: 30,50,20 - :delim: ; - :header-rows: 1 - -Since Frankfurt, we tried to create smaller repositories for the use cases and -the simulators. It shall help us to maintain the use cases and the simulators. -It shall also help to leverage and adopt existing simulators rather than -systematically re-inventing the wheel. - -The main wiki page of the Integration team can be found in -https://wiki.onap.org/display/DW/Integration+Project, you will find different -menus, Q&As, and release pages. - -Environment Installation ------------------------- - -In addition of the official OOM scripts, Integration provides some guidelines to -install your OpenStack configuration thanks to a heat template. -See :ref:`Integration heat guideline <integration-installation>` for details. - -Integration CI --------------- - -Integration project is responsible of the Continuous Integration Chains. -A guide has been created to setup your own CI chain. -See :ref:`Integration CI guideline <integration-ci>` for details. - -Stability Testing ------------------ - -Ensuring the stability of ONAP is one of the missions of the Integration team. -CI chains and stability tests are performed to help stabilising the release. -See :ref:`Integration stability tests <integration-s3p>` for details. + release-notes.rst + docs_usecases_release.rst + integration-resources.rst + integration-missions.rst diff --git a/docs/integration-CICD.rst b/docs/integration-CICD.rst new file mode 100644 index 000000000..5ac342008 --- /dev/null +++ b/docs/integration-CICD.rst @@ -0,0 +1,53 @@ +.. This work is licensed under a + Creative Commons Attribution 4.0 International License. +.. integration-CICD: + +.. integration_main-doc: + +CI/CD +===== + +.. important:: + Integration team deals with 2 different CI/CD systems. + + - Jenkins CI/CD, CI managed by LF IT and CD by Integration team + - GitLab-CI managed by Integration team + +Continuous Integration +---------------------- + +The CI part provides the following features: + +- Repository verification (format of the INFO.yaml) +- Patchset verification thanks to json/yaml/python/go/rst/md linters. These Jenkins + verification jobs are hosted in the ci-management repository. They can vote + +1/-1 on patchset submission. Integration team systematically enables linters + on any new repository +- Docker build: Integration team builds testsuite dockers and xtesting dockers. + These dockers are built then pushed to Nexus through a jjb also hosted in the + ci-management repository. + +The different verification chains are defined in https://jenkins.onap.org/: + +- CSIT: https://jenkins.onap.org/view/CSIT/ +- testsuite: https://jenkins.onap.org/view/testsuite/ +- integration: https://jenkins.onap.org/view/integration/ +- testsuite-robot-utils: https://jenkins.onap.org/view/testsuite-robot-utils/ + +The Jenkins jobs (jjb) are hosted in https://git.onap.org/ci-management/. + +Continuous Deployment +--------------------- + +GitLab CD +......... + +This CD is leveraging public gitlab-ci mechanism and used to deploy several ONAP +labs: + +- Daily Master: daily run using OOM Master +- Weekly Master: run once a week with longer tests +- Gating: run on OOM, clamp or SO patchset submission. It means a full ONAP + deployment on demand based on new patchset declared in gerrit. + +See :ref:`Integration CI guideline <integration-ci>` for details. diff --git a/docs/integration-labs.rst b/docs/integration-labs.rst new file mode 100644 index 000000000..49915c846 --- /dev/null +++ b/docs/integration-labs.rst @@ -0,0 +1,38 @@ +.. This work is licensed under a + Creative Commons Attribution 4.0 International License. +.. integration-labs: + +.. integration_main-doc: + +Integration Labs +================ + +.. important:: + The Integration team deals with several community labs: + + - The Azure staging lab + - The DT lab + - The University New Hempshire lab + +Additionally integration contributors may deal with their own lab pushing results +in the integration portal (See DT http://testresults.opnfv.org/onap-integration/dt/dt.html) + +Azure staging lab +----------------- + +An additional Azure staging lab has been created for Guilin. It is installed as +any daily/weekly/gating labs (see CI/CD sections). +Contact the Integration team to get an access. + +DT lab +------ + +The DT lab reported Master daily results in addition of Istanbul daily results. +Results are shared with the community in +`<https://logs.onap.org/onap-integration/daily/onap-master-daily-dell/>`_ + +University New Hempshire lab +---------------------------- + +Lab for community use. See `ONAP UNH lab <https://wiki.onap.org/display/DW/ONAP+UNH-IOL+Lab>`_ +for more information. diff --git a/docs/integration-missions.rst b/docs/integration-missions.rst new file mode 100644 index 000000000..421519859 --- /dev/null +++ b/docs/integration-missions.rst @@ -0,0 +1,44 @@ +.. This work is licensed under a + Creative Commons Attribution 4.0 International License. +.. _integration-missions: + +Integration Missions +==================== + +.. important:: + The Integration project is in charge of: + + - Providing testing environment + - Supporting the use case teams + - Managing ONAP CI/CD chains + - Developing tests + - Providing baseline images + - Validating the ONAP releases + +The different activities may be summarized as follows (proportions are indicative): + +- Community support +- Lab support +- Use case support +- Test development +- Management of daily/weekly CI chains +- Build baseline images +- Automate tests +- Validate the release + +For each release, the integration team provides the following artifacts: + +- A daily CI chain corresponding to the release +- Staging labs to perform the pairwise testing (when not automated) and support + the use case teams +- Baseline Java and Python images +- oparent library to manage Java dependencies +- Test suites and tools to check the various ONAP components +- Use-case documentation and artifacts +- A testsuite docker included in the ONAP cluster to execute the robot based tests +- Configuration files (scripts, Heat templates, CSAR files) to help installing + 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>`_ +for details. diff --git a/docs/integration-repositories.csv b/docs/integration-repositories.csv deleted file mode 100644 index bb585afd6..000000000 --- a/docs/integration-repositories.csv +++ /dev/null @@ -1,16 +0,0 @@ -Repository;Description;Link -integration;Historical main repository including documentation, simulators (e.g. mass PNF simulator), non robot tests (e.g. security tests, vCPE Tosca,..), ...;`link <https://gerrit.onap.org/r/admin/repos/integration>`__ -integration/csit;Repository hosting some tooling to start component functional tests in Jenkins (To be deprecated in Guilin as such tests must be reinsourced by the projects);`link <https://gerrit.onap.org/r/admin/repos/integration/csit>`__ -integration/docker/onap-java11;Java11 baseline image conformed to SECCOM recommendations;`link <https://gerrit.onap.org/r/admin/repos/integration/docker/onap-java11>`__ -integration/docker/onap-python;Python baseline image conformed to SECCOM recommendations;`link <https://gerrit.onap.org/r/admin/repos/integration/docker/onap-python>`__ -integration/simulators/dc-simulator;Data Center simulator;`link <https://gerrit.onap.org/r/admin/repos/integration/simulators/dc-simulator>`__ -integration/simulators/pnf-simulator;PNF Simulator;`link <https://gerrit.onap.org/r/admin/repos/integration/simulators/pnf-simulator>`__ -integration/simulators/ran-simulator;RAN simulator;`link <https://gerrit.onap.org/r/admin/repos/integration/simulators/ran-simulator>`__ -integration/usecases/bbs;BBS use case introduced in Dublin and extracted from global repository in frankfurt;`link <https://gerrit.onap.org/r/admin/repos/integration/usecases/bbs>`__ -integration/usecases/mdons;MDONS use case introduced in Frankfurt;`link <https://gerrit.onap.org/r/admin/repos/integration/usecases/mdons>`__ -testsuite;repository hosting the robot test suites;`link <https://gerrit.onap.org/r/admin/repos/testsuite>`__ -testsuite/heatbridge;python utils to manage the heatbridge function to enrich cloud information to AAI (deprecated);`link <https://gerrit.onap.org/r/admin/repos/testsuite/heatbridge>`__ -testsuite/oom;Helm chart for robot pod (to be deprecated in Guilin and moved back to OOM);`link <https://gerrit.onap.org/r/admin/repos/testsuite/oom>`__ -testsuite/python-testing-utils;Python and robot util libraries used for robot tests;`link <https://gerrit.onap.org/r/admin/repos/testsuite/python-testing-utils>`__ -demo;Historical repository to host use case artifacts (heat templates, json files,..);`link <https://gerrit.onap.org/r/admin/repos/demo>`__ -oparent;Java dependencies for JAVA projects;`link <https://gerrit.onap.org/r/admin/repos/oparent>`__ diff --git a/docs/integration-repositories.rst b/docs/integration-repositories.rst new file mode 100644 index 000000000..2501c7321 --- /dev/null +++ b/docs/integration-repositories.rst @@ -0,0 +1,115 @@ +.. This work is licensed under a + Creative Commons Attribution 4.0 International License. +.. integration-repositories: + +Integration repositories +======================== + +.. important:: + The Integration project deals with lots of code repositories. + +Integration +----------- + +The integration repository is the historical repository. +As a consequence it includes several elements in the same repository: + +- Deployment scripts (deployment directory) +- Tests: the first non robot tests (security, vCPE,..) +- Simulators/emulators (test/mocks) +- Integration and use cases documentation (docs) +- Tools (bootstrap, S3Ptools) + +Since Frankfurt version, we created more smaller repositories especially for the use +cases and the simulators. +It shall help improving the maintenance of the different elements. +It shall also help identifying, leveraging and adopting existing simulators +rather than systematically re-inventing the wheel. + +.. note:: + There is a new section of repositories - pipelines. These repositories are migrated for Orange GitLab project. + Code on these repositories is planned to be used to run ONAP tests GitLab CI/CD pipelines on `GitLab ONAP integration group <https://gitlab.com/onap/integration>`__ + +.. csv-table:: Integration Repositories + :file: ./files/csv/repo-integration.csv + :widths: 30,50,20 + :delim: ; + :header-rows: 1 + +.. csv-table:: Integration Simulators + :file: ./files/csv/repo-simulators.csv + :widths: 30,50,20 + :delim: ; + :header-rows: 1 + +.. csv-table:: Integration Pipelines + :file: ./files/csv/repo-pipelines.csv + :widths: 30,50,20 + :delim: ; + :header-rows: 1 + +Testsuite +--------- + +The testsuite repository and its sub repositories deal exclusively with tests. + +The testsuite repository includes all the robotframework scripts. +The robot pod that can be installed as part of the ONAP cluster is built from +this repository. + +Several tooling repositories are associated with the robot tests (heatbridge, +robot-python-testing-utils). + +.. csv-table:: Testsuite Repositories + :file: ./files/csv/repo-testsuite.csv + :widths: 30,50,20 + :delim: ; + :header-rows: 1 + +Demo +---- + +In this repository you will find any artifacts needed for demo, PoC and use cases +if they do not have their own repository (mainly old use cases). + +.. csv-table:: Demo Repository + :file: ./files/csv/repo-demo.csv + :widths: 30,50,20 + :delim: ; + :header-rows: 1 + +Oparent +------- + +.. csv-table:: Oparent Repository + :file: ./files/csv/repo-oparent.csv + :widths: 30,50,20 + :delim: ; + :header-rows: 1 + +Archived repositories +--------------------- + +Some repositories are archived and marked as "read-only" due to the lack of any activity in them. + +.. csv-table:: Archived Repositories + :file: ./files/csv/repo-archived.csv + :widths: 30,50,20 + :delim: ; + :header-rows: 1 + + +External repositories +--------------------- + +Additionally, the Integration team also deals with external gitlab.com +repositories. + +.. important:: + All of these repositories should be migrated into ONAP's Gerrit + +.. csv-table:: Integration external repositories table + :file: ./files/csv/repo-integration-external.csv + :widths: 30,50,20 + :delim: ; + :header-rows: 1 diff --git a/docs/integration-resources.rst b/docs/integration-resources.rst new file mode 100644 index 000000000..4af90c15d --- /dev/null +++ b/docs/integration-resources.rst @@ -0,0 +1,16 @@ +.. This work is licensed under a + Creative Commons Attribution 4.0 International License. +.. _integration-resources: + +Integration Resources +===================== + +.. toctree:: + :glob: + + integration-repositories.rst + integration-labs.rst + integration-tests.rst + integration-CICD.rst + integration-simulators.rst + integration-tooling.rst diff --git a/docs/integration-s3p.rst b/docs/integration-s3p.rst index 49c67850f..13e36c17a 100644 --- a/docs/integration-s3p.rst +++ b/docs/integration-s3p.rst @@ -1,204 +1,207 @@ +.. This work is licensed under a + Creative Commons Attribution 4.0 International License. .. _integration-s3p: -ONAP Maturity Testing Notes ---------------------------- - -Historically integration team used to execute specific stability and resilience -tests on target release. For frankfurt a stability test was executed. -Openlab, based on Frankfurt RC0 dockers was also observed a long duration -period to evaluate the overall stability. -Finally the CI daily chain created at Frankfurt RC0 was also a precious indicator -to estimate the solution stability. - -No resilience or stress tests have been executed due to a lack of resources -and late availability of the release. The testing strategy shall be amended in -Guilin, several requirements have been created to improve the S3P testing domain. +:orphan: Stability ========= -ONAP stability was tested through a 72 hour test. -The intent of the 72 hour stability test is not to exhaustively test all -functions but to run a steady load against the system and look for issues like -memory leaks that cannot be found in the short duration install and functional -testing during the development cycle. - -Integration Stability Testing verifies that the ONAP platform remains fully -functional after running for an extended amounts of time. -This is done by repeated running tests against an ONAP instance for a period of -72 hours. - -:: - - **The 72 hour stability run result was PASS** - -The onboard and instantiate tests ran for over **115 hours** before environment -issues stopped the test. There were errors due to both tooling and environment -errors. - -The overall memory utilization only grew about **2%** on the work nodes despite -the environment issues. Interestingly the kubernetes ochestration node memory -grew more which could mean we are over driving the API's in some fashion. - -We did not limit other tenant activities in Windriver during this test run and -we saw the impact from things like the re-installation of SB00 in the tenant -and general network latency impacts that caused openstack to be slower to -instantiate. -For future stability runs we should go back to the process of shutting down -non-critical tenants in the test environment to free up host resources for -the test run (or other ways to prevent other testing from affecting the stability -run). - -The control loop tests were **100% successful** and the cycle time for the loop was -fairly consistent despite the environment issues. Future control loop stability -tests should consider doing more policy edit type activites and running more -control loop if host resources are available. The 10 second VES telemetry event -is quite aggressive so we are sending more load into the VES collector and TCA -engine during onset events than would be typical so adding additional loops -should factor that in. The jenkins jobs ran fairly well although the instantiate -Demo vFWCL took longer than usual and should be factored into future test planning. - - -Methodology -~~~~~~~~~~~ +.. important:: + The Release stability has been evaluated by: -The Stability Test has two main components: + - The daily CI/CD chain + - Stability tests -- Running "ete stability72hr" Robot suite periodically. This test suite - verifies that ONAP can instantiate vDNS, vFWCL, and VVG. -- Set up vFW Closed Loop to remain running, then check periodically that the - closed loop functionality is still working. +.. note: + The scope of these tests remains limited and does not provide a full set of + KPIs to determinate the limits and the dimensioning of the ONAP solution. -The integration-longevity tenant in Intel/Windriver environment was used for the -72 hour tests. +CI results +---------- -The onap-ci job for "Project windriver-longevity-release-manual" was used for -the deployment with the OOM set to frankfurt and Integration branches set to -master. Integration master was used so we could catch the latest updates to -integration scripts and vnf heat templates. +As usual, a daily CI chain dedicated to the release is created after RC0. -The jenkins job needs a couple of updates for each release: +The daily results can be found in `LF DT lab daily results web site <https://logs.onap.org/onap-integration/daily/onap-daily-dt-oom-master/>`_. -- Set the integration branch to 'origin/master' -- Modify the parameters to deploy.sh to specify "-i master" and "-o frankfurt" - to get integration master an oom frankfurt clones onto the nfs server. +.. image:: files/s3p/jakarta-dashboard.png + :align: center -The path for robot logs on dockerdata-nfs changed in Frankfurt so the -/dev-robot/ becomes /dev/robot -.. note:: - For Frankfurt release, the stability test has been executed on an - kubernetes infrastructure based on El Alto recommendations. The kubernetes - version was 1.15.3 (frankfurt 1.15.11) and the helm version was 2.14.2 - (frankfurt 2.16.6). However the ONAP dockers were updated to Frankfurt RC2 - candidate versions. The results are informative and can be compared with - previous campaigns. The stability tests used robot container image - **1.6.1-STAGING-20200519T201214Z**. Robot container was patched to use GRA_API - since VNF_API has been deprecated. +Infrastructure Healthcheck Tests +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Shakedown consists of creating some temporary tags for stability72hrvLB, -stability72hrvVG,stability72hrVFWCL to make sure each sub test ran successfully -(including cleanup) in the environment before the jenkins job started with the -higher level testsuite tag stability72hr that covers all three test types. +These tests deal with the Kubernetes/Helm tests on ONAP cluster. -Clean out the old buid jobs using a jenkins console script (manage jenkins) +The global expected criteria is **100%**. -:: +The onap-k8s and onap-k8s-teardown, providing a snapshop of the onap namespace +in Kubernetes, as well as the onap-helm tests are expected to be PASS. - def jobName = "windriver-longevity-stability72hr"= - def job = Jenkins.instance.getItem(jobName) - job.getBuilds().each { it.delete() } - job.nextBuildNumber = 1 - job.save() +.. image:: files/s3p/istanbul_daily_infrastructure_healthcheck.png + :align: center +Healthcheck Tests +~~~~~~~~~~~~~~~~~ -appc.properties updated to apply the fix for DMaaP message processing to call -http://localhost:8181 for the streams update. +These tests are the traditionnal robot healthcheck tests and additional tests +dealing with a single component. -Results: 100% PASS -~~~~~~~~~~~~~~~~~~ -=================== ======== ========== ======== ========= ========= -Test Case Attempts Env Issues Failures Successes Pass Rate -=================== ======== ========== ======== ========= ========= -Stability 72 hours 77 19 0 58 100% -vFW Closed Loop 60 0 0 100 100% -**Total** 137 19 0 158 **100%** -=================== ======== ========== ======== ========= ========= - -Detailed results can be found at https://wiki.onap.org/display/DW/Frankfurt+Stability+Run+Notes - -.. note:: - - Overall results were good. All of the test failures were due to - issues with the unstable environment and tooling framework. - - JIRAs were created for readiness/liveness probe issues found while - testing under the unstable environment. Patches applied to oom and - testsuite during the testing helped reduce test failures due to - environment and tooling framework issues. - - The vFW Closed Loop test was very stable and self recovered from - environment issues. - -Resources overview -~~~~~~~~~~~~~~~~~~ -============ ====================== =========== ========== ========== -Date #1 CPU #1 RAM CPU* RAM** -============ ====================== =========== ========== ========== -May 20 18:45 dcae-tca-anaytics:511m appc:2901Mi 1649 36092 -May 21 12:33 dcae-tca-anaytics:664m appc:2901Mi 1605 38221 -May 22 09:35 dcae-tca-anaytics:425m appc:2837Mi 1459 38488 -May 23 11:01 cassandra-1:371m appc:2849Mi 1829 39431 -============ ====================== =========== ========== ========== - -.. note:: - - Results are given from the command "kubectl -n onap top pods | sort -rn -k 3 - | head -20" - - * sum of the top 20 CPU consumption - - ** sum of the top 20 RAM consumption +The expectation is **100% OK**. -CI results -========== +.. image:: files/s3p/istanbul_daily_healthcheck.png + :align: center + +Smoke Tests +~~~~~~~~~~~ -A daily Frankfurt CI chain has been created after RC0. +These tests are end to end and automated use case tests. +See the :ref:`the Integration Test page <integration-tests>` for details. -The evolution of the full healthcheck test suite can be described as follows: +The expectation is **100% OK**. -|image1| +.. figure:: files/s3p/istanbul_daily_smoke.png + :align: center -Full healthcheck testsuite verifies the status of each component. It is -composed of 47 tests. The success rate from the 9th to the 28th was never under -95%. +Security Tests +~~~~~~~~~~~~~~ -4 test categories were defined: +These tests are tests dealing with security. +See the :ref:`the Integration Test page <integration-tests>` for details. -- infrastructure healthcheck: test of ONAP kubernetes cluster and help chart status -- healthcheck tests: verification of the components in the target deployment - environment -- smoke tests: basic VM tests (including onboarding/distribution/instantiation), - and automated use cases (pnf-registrate, hvves, 5gbulkpm) -- security tests +Waivers have been granted on different projects for the different tests. +The list of waivers can be found in +https://git.onap.org/integration/seccom/tree/waivers?h=jakarta. -The security target (66% for Frankfurt) was reached after the RC1. A regression -due to the automation of the hvves use case (triggering the exposition of a -public port in HTTP) was fixed on the 28th of May. +nodeport_check_certs test is expected to fail. Even tremendous progress have +been done in this area, some certificates (unmaintained, upstream or integration +robot pods) are still not correct due to bad certificate issuers (Root CA +certificate non valid) or extra long validity. Most of the certificates have +been installed using cert-manager and will be easily renewable. -|image2| +The expectation is **80% OK**. The criteria is met. -Orange Openlab -============== +.. figure:: files/s3p/istanbul_daily_security.png + :align: center -The Orange Openlab is a community lab targeting ONAP end user. It provides an -ONAP and cloud resources to discover ONAP. -A Frankfurt pre-RC0 version was installed beginning of May. The usual gating -testing suite was run daily in addition of the traffic generated by the lab -users. The VM instantiation has been working well without any reinstallation -over the **27** last days. +Stability tests +--------------- -Resilience -========== +Stability tests have been performed on Istanbul release: -The resilience test executed in El Alto was not realized in Frankfurt. +- SDC stability test +- Parallel instantiation test -.. |image1| image:: files/s3p/daily_frankfurt1.png - :width: 6.5in +The results can be found in the weekly backend logs +https://logs.onap.org/onap-integration/weekly/onap_weekly_pod4_istanbul. + +SDC stability test +~~~~~~~~~~~~~~~~~~ -.. |image2| image:: files/s3p/daily_frankfurt2.png - :width: 6.5in +In this test, we consider the basic_onboard automated test and we run 5 +simultaneous onboarding procedures in parallel during 24h. + +The basic_onboard test consists in the following steps: + +- [SDC] VendorOnboardStep: Onboard vendor in SDC. +- [SDC] YamlTemplateVspOnboardStep: Onboard vsp described in YAML file in SDC. +- [SDC] YamlTemplateVfOnboardStep: Onboard vf described in YAML file in SDC. +- [SDC] YamlTemplateServiceOnboardStep: Onboard service described in YAML file + in SDC. + +The test has been initiated on the Istanbul weekly lab on the 14th of November. + +As already observed in daily|weekly|gating chain, we got race conditions on +some tests (https://jira.onap.org/browse/INT-1918). + +The success rate is expected to be above 95% on the 100 first model upload +and above 80% until we onboard more than 500 models. + +We may also notice that the function test_duration=f(time) increases +continuously. At the beginning the test takes about 200s, 24h later the same +test will take around 1000s. +Finally after 36h, the SDC systematically answers with a 500 HTTP answer code +explaining the linear decrease of the success rate. + +The following graphs provides a good view of the SDC stability test. + +.. image:: files/s3p/istanbul_sdc_stability.png + :align: center + +.. csv-table:: S3P Onboarding stability results + :file: ./files/csv/s3p-sdc.csv + :widths: 60,20,20,20 + :delim: ; + :header-rows: 1 + +.. important:: + The onboarding duration increases linearly with the number of on-boarded + models, which is already reported and may be due to the fact that models + cannot be deleted. In fact the test client has to retrieve the list of + models, which is continuously increasing. No limit tests have been + performed. + However 1085 on-boarded models is already a vry high figure regarding the + possible ONAP usage. + Moreover the mean duration time is much lower in Istanbul. + It explains why it was possible to run 35% more tests within the same + time frame. + +Parallel instantiations stability test +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The test is based on the single test (basic_vm) that can be described as follows: + +- [SDC] VendorOnboardStep: Onboard vendor in SDC. +- [SDC] YamlTemplateVspOnboardStep: Onboard vsp described in YAML file in SDC. +- [SDC] YamlTemplateVfOnboardStep: Onboard vf described in YAML file in SDC. +- [SDC] YamlTemplateServiceOnboardStep: Onboard service described in YAML file + in SDC. +- [AAI] RegisterCloudRegionStep: Register cloud region. +- [AAI] ComplexCreateStep: Create complex. +- [AAI] LinkCloudRegionToComplexStep: Connect cloud region with complex. +- [AAI] CustomerCreateStep: Create customer. +- [AAI] CustomerServiceSubscriptionCreateStep: Create customer's service + subscription. +- [AAI] ConnectServiceSubToCloudRegionStep: Connect service subscription with + cloud region. +- [SO] YamlTemplateServiceAlaCarteInstantiateStep: Instantiate service described + in YAML using SO a'la carte method. +- [SO] YamlTemplateVnfAlaCarteInstantiateStep: Instantiate vnf described in YAML + using SO a'la carte method. +- [SO] YamlTemplateVfModuleAlaCarteInstantiateStep: Instantiate VF module + described in YAML using SO a'la carte method. + +10 instantiation attempts are done simultaneously on the ONAP solution during 24h. + +The results can be described as follows: + +.. image:: files/s3p/istanbul_instantiation_stability_10.png + :align: center + +.. csv-table:: S3P Instantiation stability results + :file: ./files/csv/s3p-instantiation.csv + :widths: 60,20,20,20 + :delim: ; + :header-rows: 1 + +The results are good with a success rate above 95%. After 24h more than 1300 +VNF have been created and deleted. + +As for SDC, we can observe a linear increase of the test duration. This issue +has been reported since Guilin. For SDC as it is not possible to delete the +models, it is possible to imagine that the duration increases due to the fact +that the database of models continuously increases. Therefore the client has +to retrieve an always bigger list of models. +But for the instantiations, it is not the case as the references +(module, VNF, service) are cleaned at the end of each test and all the tests +use the same model. Then the duration of an instantiation test should be +almost constant, which is not the case. Further investigations are needed. + +.. important:: + The test has been executed with the mariadb-galera replicaset set to 1 + (3 by default). With this configuration the results during 24h are very + good. When set to 3, the error rate is higher and after some hours + most of the instantiation are failing. + However, even with a replicaset set to 1, a test on Master weekly chain + showed that the system is hitting another limit after about 35h + (https://jira.onap.org/browse/SO-3791). diff --git a/docs/integration-simulators.rst b/docs/integration-simulators.rst new file mode 100644 index 000000000..7f6688f05 --- /dev/null +++ b/docs/integration-simulators.rst @@ -0,0 +1,111 @@ +.. This work is licensed under a + Creative Commons Attribution 4.0 International License. +.. integration-tooling: + +.. _integration-simulators: + +Simulators +========== + +Simulators are regularly created for use cases. The goal of this section is to: + +- Highlight the existing Simulators +- Provide recommendations when starting developing a new simulator + +.. important:: + Before developing a new simulator, check that it does not exist...and + refactor/contribute to existing simulators rather than recreating new ones. + + +Existing simulators +------------------- + +.. csv-table:: Simulators + :file: ./files/csv/simulators.csv + :widths: 10,50,20,20 + :delim: ; + :header-rows: 1 + + +Recommendations +--------------- + +The simulator code +.................. + +We recommend to create a dedicated repository (ask Integration team). + +.. csv-table:: Simulator repositories + :file: ./files/csv/repo-simulators.csv + :widths: 30,50,20 + :delim: ; + :header-rows: 1 + + +Dockerization +............. + +From this repository, create a jenkins job to automatically build the dockers. + +Helm Chart +.......... + +It is recommended to create a helm chart in order to run the simulators. + + +Wrapper for simulators +...................... + +1. In order to deploy the Helm release with a simulator, place a YAML file +describing the Helm release in src/onaptests/templates/helm_charts. + + The structure of the YAML file should be like in the example below. + Dependencies contain all the charts that need to be pulled. + + .. code-block:: YAML + + # Helm release information + api_version: # API_VERSION + app_version: # APP_VERSION + chart_name: # SIMULATOR_NAME + version: # CHART_VERSION + + # Helm charts that need to be pulled + dependencies: + - name: # SIMULATOR_NAME + version: # CHART_VERSION + repository: # URL + local_repo_name: # REPO_NAME + +2. Install the Helm release: + + .. code-block:: Python + + from onaptests.steps.wrapper.helm_charts import HelmChartStep + + chart = HelmChartStep( + cleanup = BOOLEAN, + chart_info_file = YAML_FILE_NAME # name, not the path + ) + chart.execute() + +3. Start the simulator via an API call: + + .. code-block:: Python + + start = SimulatorStartStep( + cleanup = BOOLEAN, + https = BOOLEAN, + host = HOSTNAME, + port = PORT, + endpoint = START_ENDPOINT, # if applicable + method = REQUEST_METHOD, # GET, POST etc. + data = PAYLOAD # {"json": {...}, ...} + ) + start.execute() + +4. Undeploy the Helm release: + + .. code-block:: Python + + chart.cleanup() diff --git a/docs/integration-tests.rst b/docs/integration-tests.rst new file mode 100644 index 000000000..6453e55ef --- /dev/null +++ b/docs/integration-tests.rst @@ -0,0 +1,159 @@ +.. This work is licensed under a + Creative Commons Attribution 4.0 International License. +.. _integration-tests: + +Tests +===== + +.. important:: + Integration is in charge of several types of tests: + + - Use Cases: developed by use case teams, usually complex, demonstrating high value capabilities of ONAP. They may be partially automated and even + integrated in CD. + - CSIT Tests: functional tests created by the projects, partially hosted in CSIT repository + - Automatic Test Cases: these use cases are usually more simple and aim to validate that ONAP is working properly. + These tests have been developed to validate ONAP as a software solution. + In theory all the main functions shall be covered by such tests in order to have more robust CI/CD and then avoid regressions. + These tests are usually developed and maintained by the integration team. + +We may also indicate that when the development of the test framework python-onapsdk +follows standard development quality rules and imposes the creation of +unit/functional/integration tests. +As an example python-onapsdk requires a unit test coverage of 98% before merging +a new feature, which is far above the project criteria in SonarCloud today. + +Use Cases +--------- + +The use cases of the last release are described in +:ref:`Verified Use cases <docs_usecases_release>`. + +CSIT Tests +---------- + +The CSIT tests are functional tests executed by the projects on mocked +environment to validate their components. +Historically it was hosted in a CSIT repository. + +Integration team invited the projects to bring back such tests back to home +repository for 2 main reasons: + +- integration cannot be a bottleneck: +2/merge from integration needed for each + project +- most of the tests are abandoned and not maintained when hosted in a third party + repository leading to CI/CD resource waste and misleading test reporting + +Automated 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. + +.. hint:: + Automatic tests are currently divided in 4 different categories: + + - infrastructure-healthcheck: tests from OOM checking the ONAP namespace, certificates... + - healthcheck: basic tests on components + - smoke tests: end to end tests + - security tests + +A dashboard summarizing the status and providing the links to the test result +page or the logs is automatically created at the end of the execution of the +tests. + +.. figure:: files/tests/test-dashboard.png + + Test dashboard (Guilin version) + +All the pages and artifacts are pushed to LF backend: + +- Daily chains: https://logs.onap.org/onap-integration/daily +- Weekly chains: https://logs.onap.org/onap-integration/weekly +- Gating chains: the result link is indicated in gerrit + +A video has been recorded to help launching some of the automated tests on ONAP Guilin. +See `Running ONAP tests in Guilin Video <https://www.youtube.com/watch?v=ABvuJfyGDmw>`_ + +Infrastructure Healthcheck Tests +................................ + +.. csv-table:: Infrastructure Healthcheck Tests + :file: ./files/csv/tests-infrastructure-healthcheck.csv + :widths: 20,40,20,20 + :delim: ; + :header-rows: 1 + +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 +the installation (onap-k8s) and at the end of the test execution (onap-k8s-teardown) +in order to collect the logs of the different components during the test execution. + +.. figure:: files/tests/test-onap-k8s.png + +Healthcheck Tests +................. + +.. csv-table:: Healthcheck Tests + :file: ./files/csv/tests-healthcheck.csv + :widths: 20,40,20,20 + :delim: ; + :header-rows: 1 + +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 +........... + +.. csv-table:: Smoke Tests + :file: ./files/csv/tests-smoke.csv + :widths: 20,40,20,20 + :delim: ; + :header-rows: 1 + +There are 2 main families of smoke tests: + +* RobotFramework based tests, usually run from inside the cluster as a k8s job +* Pythonsdk based tests. These tests (also known as onaptests) are consuming + several SDKs: the Openstack and Kubernetes SDK for the management of the cloud + resources and the python ONAP SDK for the interactions with ONAP + +To launch the the robot based tests, please see +`Robot smoke test README <https://git.onap.org/integration/xtesting/tree/smoke-usecases-robot/README.md>`_ +Standard Robot html pages are generated. See :ref:`Robot page <docs_robot>`. + +To launch the pythonsdk based tests, please see +`Python smoke test README <https://git.onap.org/integration/xtesting/tree/smoke-usecases-pythonsdk/README.md>`_ + +.. note: + Please note that the OpenStack minimal version is pike. + +An html page is generated by the pythonsdk-test tests. + +.. figure:: files/tests/test-basic-cnf.png + +Security Tests +............... + +.. csv-table:: Security Tests + :file: ./files/csv/tests-security.csv + :widths: 20,40,20,20 + :delim: ; + :header-rows: 1 + +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/>`_. + +Stability tests +--------------- + +Ensuring the stability of ONAP is one of the missions of the Integration team. +CI chains and stability tests are performed to help stabilising the release. +See :ref:`Integration stability tests <integration-s3p>` for details. diff --git a/docs/integration-tooling.rst b/docs/integration-tooling.rst new file mode 100644 index 000000000..d615e7e27 --- /dev/null +++ b/docs/integration-tooling.rst @@ -0,0 +1,214 @@ +.. 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 privileged 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. + +Integration Project +------------------- + +Integration portal +~~~~~~~~~~~~~~~~~~ + +A portal is built to report the status of the different labs collaborating in +Integration, see http://testresults.opnfv.org/onap-integration/ + +.. figure:: files/CI/ONAP_CI_3.png + :align: center + :width: 6.5in + +The code of this web site is shared on a public gitlab project. + + +Communication channels +~~~~~~~~~~~~~~~~~~~~~~ + +The main communication channel for real time support is the official ONAP +Slack #integration-team chan (https://onapproject.slack.com/). + +You can also send a mail to onap-discuss AT lists.onap.org +with [ONAP] [Integration] prefix in the title. + +Repository management +~~~~~~~~~~~~~~~~~~~~~ + +Since Integration team manages few dozens of different repositories a tool was provided to aid the process of mass editing the INFO.yaml files. It can be found `here <https://git.onap.org/integration/tree/ptl/edit_committers_info>`__. + +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 they are not integrated in CI/CD. + + +Python ONAP SDK +............... + +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://gerrit.onap.org/r/admin/repos/integration/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 companion 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>`_ + +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/>`_ + +Integration Test database +~~~~~~~~~~~~~~~~~~~~~~~~~ + +The integration team shares a Test Result Database with the OPNFV project. All +the test results of the CD are automatically pushed to this database. +It is possible to retrieve the results through the Test API associated with this +test Database. + +The following information are available: + +- List of pods allowed to push results: http://testresults.opnfv.org/onap/api/v1/pods +- List of projects that declared test cases for CI/CD: http://testresults.opnfv.org/onap/api/v1/projects +- List of integration test cases: + http://testresults.opnfv.org/onap/api/v1/projects/integration/cases +- List of security test cases: + http://testresults.opnfv.org/onap/api/v1/projects/security/cases +- Results with lots of possible filter combinations: http://testresults.opnfv.org/onap/api/v1/results?last=3 + +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://docs.anuket.io/en/stable-lakelse/testing/ecosystem/overview.html#test-api-description>`_. + +Any company running ONAP Integration tests can be referenced to push their results +to this database. +This Database is hosted on a LF OPNFV server. Results are backuped daily. +Integration committers can have access to this server. + +VNF demo Artifacts +~~~~~~~~~~~~~~~~~~ + +VNF demo artifacts are hosted in the demo repositories and published in +https://nexus.onap.org/content/repositories/releases/org/onap/demo/vnf/. diff --git a/docs/onap-integration-ci.rst b/docs/onap-integration-ci.rst index 99a54323a..150c82b40 100644 --- a/docs/onap-integration-ci.rst +++ b/docs/onap-integration-ci.rst @@ -1,14 +1,17 @@ .. _integration-ci: +:orphan: + Integration Continuous Integration Guide ---------------------------------------- -Continuous Integration is key due to the complexity of the ONAP projects. -Several chains have been created: +.. important:: + Continuous Integration is key due to the complexity of the ONAP projects. + Several chains have been created: -- Daily stable chain -- Daily master chain -- Gating: On demand deployment of a full ONAP solution to validate patchsets + - Daily stable chain + - Daily master chain + - Gating: On demand deployment of a full ONAP solution to validate patchsets They are run on different environments (Orange labs, DT labs, Azure Cloud). @@ -77,9 +80,6 @@ can be used to visualize them. A web site has been created to centralize the links on http://testresults.opnfv.org/onap-integration/index.html -.. figure:: files/CI/ONAP_CI_3.png - :align: center - For Gating and gitlab.com based CI chains, the pipelines consist in pipelines of pipelines managed through the chaining of .gitlab-ci.yml file thanks to an Open Source deployment called chained-ci (https://gitlab.com/Orange-OpenSource/lfn/ci_cd/chained-ci). @@ -88,6 +88,7 @@ figure below: .. figure:: files/CI/ONAP_CI_1.png :align: center + :width: 10in If you click on any element of the chain, you will open a new window: @@ -99,12 +100,14 @@ created to summarize the tests and grant access to their associated logs: .. figure:: files/CI/ONAP_CI_8.png :align: center + :width: 6.5in Additionnaly, for the daily chain, another page displays the results as time series, allowing to see the evolution of the tests over time. .. figure:: files/CI/ONAP_CI_9.png :align: center + :width: 6.5in Setup Your Own CI Chains @@ -126,44 +129,3 @@ You should be able to chain your automation projects: If you want to report your results to the community, do not hesitate to contact the integration team. The Test database is public but the pods must be declared to be allowed to report results from third party labs. - - -ONAP Integration Testing Gate -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -5 categories have been defined for the ONAP integration testing gate: - -* infrastructure healthcheck: verify ONAP from a k8S perspective. It includes - 2 tests: onap-k8s (all the deployments, jobs, statefulste,..must be OK at - the end of an installation), onap-helm (all the helm chart must be - completed at the end of the installation) -* healthcheck: the traditionnal robot tests run from the cluster to perform - tests on the different components. -* smoke-usecases: End to end tests -* candidate-usecases: New end to end tests introduced in the automation chain - for the release -* security tests (security of kubernetes (CVE, CIS tests) and ONAP (exposed - ports, check the containers run as root,...)) -* benchmarking (robustness, stress tests): not yet available - -All these tests have been packaged thanks to the OPNFV Open Source tool xtesting. -Xtesting is a python package allowing to unify the way to declare, run tests. It -also ensures a consistent way to get the test results whatever the test framework -used (python, robotframework, bash, ...). It includes the mechanism to -automatically push the results to the test database using the test API. -It simplifies the integration in CI. - -The package can be found here https://pypi.org/project/xtesting/. - -The different ONAP xtesting dockers can be found on https://gitlab.com/Orange-OpenSource/lfn/onap/integration/xtesting/container_registry - -As an illustration, you can run the infrastructure healthcheck by typing the -following command:: - - docker run -v <the kube config>:/root/.kube/config -v <result directory>: - /var/lib/xtesting/results registry.gitlab.com/orange-opensource/lfn/onap/integration/xtesting/infra-healthcheck:latest - -All the xtesting tests are included in Daily and gating chains. -Please note that you can build your own onap-xtesting docker if you want to -include your tests. See https://wiki.onap.org/pages/viewpage.action?pageId=79202765 -for details. diff --git a/docs/onap-oom-heat.rst b/docs/onap-oom-heat.rst index 848af72ef..13e6ca6db 100644 --- a/docs/onap-oom-heat.rst +++ b/docs/onap-oom-heat.rst @@ -1,5 +1,7 @@ .. _integration-installation: +:orphan: + Integration Environment Installation ------------------------------------- @@ -22,10 +24,10 @@ must be adapted according to your context. Source files ~~~~~~~~~~~~ -- HEAT template files: https://git.onap.org/integration/tree/deployment/heat/onap-rke?h=frankfurt -- Sample OpenStack RC file: https://git.onap.org/integration/tree/deployment/heat/onap-rke/env/windriver/Integration-SB-00-openrc?h=frankfurt -- Sample environment file: https://git.onap.org/integration/tree/deployment/heat/onap-rke/env/windriver/onap-oom.env?h=frankfurt -- Deployment script: https://git.onap.org/integration/tree/deployment/heat/onap-rke/scripts/deploy.sh?h=frankfurt +- HEAT template files: https://git.onap.org/integration/tree/deployment/heat/onap-rke +- Sample OpenStack RC file: https://git.onap.org/integration/tree/deployment/heat/onap-rke/env/windriver/Integration-SB-00-openrc +- Sample environment file: https://git.onap.org/integration/tree/deployment/heat/onap-rke/env/windriver/onap-oom.env +- Deployment script: https://git.onap.org/integration/tree/deployment/heat/onap-rke/scripts/deploy.sh Heat Template Description @@ -33,7 +35,7 @@ Heat Template Description The ONAP Integration Project provides a sample HEAT template that fully automates the deployment of ONAP using OOM as described in -OOM documentation (https://docs.onap.org/en/frankfurt/guides/onap-developer/settingup/index.html#installing-onap). +OOM documentation. The ONAP OOM HEAT template deploys the entire ONAP platform. It spins up an HA-enabled Kubernetes cluster, and deploys ONAP using OOM onto diff --git a/docs/release-notes.rst b/docs/release-notes.rst index 4f38d5892..07ba0b9f3 100644 --- a/docs/release-notes.rst +++ b/docs/release-notes.rst @@ -3,106 +3,117 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. http://creativecommons.org/licenses/by/4.0 -Integration Release Notes -========================= +Integration Kohn Release Notes +============================== + +.. csv-table:: Integration Releases + :file: ./files/csv/release-integration-ref.csv + :widths: 50,50 + :delim: ; + :header-rows: 1 + +.. important:: + + - New repositories (see dedicated section) + - Bug fixes + + Quick Links: + + - `Kohn Integration page <https://wiki.onap.org/display/DW/Integration+Kohn>`_ + - `Kohn Integration JIRA follow-up <https://wiki.onap.org/display/DW/Kohn+Integration+Blocking+points>`_ + - `Kohn Integration weather Board <https://wiki.onap.org/display/DW/0%3A+Integration+Weather+Board+for+Kohn+Release>`_ + +Code changes +------------ Integration Repo ----------------- +................. + +:Release Date: 2022-10-27 -Version: 6.0.0 -.............. -:Release Date: 2020-06-15 +Version: 11.0.0 (aka Kohn) +^^^^^^^^^^^^^^^^^^^^^^^^^^ -**New Features** +.. csv-table:: Integration Changes + :file: ./files/csv/release-integration-features.csv + :widths: 30,70 + :delim: ; + :header-rows: 1 -- provide a new testsuite docker version (1.6.3) including several test updates - for the different tests -- Creation of new repositories to host the use cases: bbs, mdons -- Creation of new repositories to host the simulators: dc-simulator, ran-simulator, - pnf-simulator -- Creation of new repositories to host baseline images: java11, python -- Update oparent library to fix security Vulnerabilities -- Support new use cases (mdons, vCPE_tosca,..) -- Creation of a web page to host CI daily results -- Creation and Integration in CI of new security tests (http public end points, - rooted pods, kubernetes CIS verification, jdpw ports) -- Update of the onap-k8s use case to report the full status of the cluster after - the installation and provide a dashboard -- Include healthdist and postinstall robot tests in healthcheck tests -- Add new smoke use cases in CI (pnf-registrate, 5gbulkpm,...) -Quick Links: +Onaptests (pythonsdk_tests) +........................... - - `Integration project page <https://wiki.onap.org/display/DW/Integration+Project>`_ - - ` Frankfurt use testing status page <https://wiki.onap.org/display/DW/2%3A+Frankfurt+Release+Integration+Testing+Status>` +Main changes: -ONAP Maturity Testing Notes ---------------------------- +.. csv-table:: pythonsdk_tests Changes + :file: ./files/csv/release-pythonsdk-features.csv + :widths: 30,70 + :delim: ; + :header-rows: 1 -A Frankfurt daily CI chain has bee put in place after the RC0 milestone. This CI -chain is used to track the stability of the release from the RC0. it will be -maintained as the latest stable CI branch and replaces the El Alto branch. -The daily results can be found in <https://gating-results.onap.eu/results/>. -A 72 stability test has been executed after RC1. +Robot (Testsuite) +................. -See :ref:`S3P page<integration-s3p>` for further details. +Version: 1.11.0 +^^^^^^^^^^^^^^^ -Verified Use Cases and Functional Requirements ----------------------------------------------- +Main changes: + +.. csv-table:: Testsuite Changes + :file: ./files/csv/release-testsuite-features.csv + :widths: 30,70 + :delim: ; + :header-rows: 1 -The Integration team verified 31 use cases. -The details can be found at -:ref:`Verified Use Cases and Functional Requirements <docs_usecases>` session. O-Parent --------- +........ + +Version: 3.3.2 +^^^^^^^^^^^^^^ -Version: 3.0.2 -.............. +.. csv-table:: Oparent Changes + :file: ./files/csv/release-oparent-features.csv + :widths: 30,70 + :delim: ; + :header-rows: 1 -:Release Date: 2020-05-08 +Demo Artifacts (Heat Templates) +............................... -**New Features** +Version: 1.11.0 +^^^^^^^^^^^^^^^ -- Update tomcat 9.0.30 -- Update latest security dependencies -- Update settings.xml to use https maven -- Update sonar configuration -- Update checkstyle rules to exclude methods -- Upgrade oparent to checkstyle 8.27 -- Revert "update version of checkstyle for latest google style and jdk 8" -- update version of checkstyle for latest google style and jdk 8 -- Add compiler-plugin example -- Uprev to 3.0.0 for Java 11 -- qos logback to 1.2.3 +.. csv-table:: Demo Changes + :file: ./files/csv/release-demo-features.csv + :widths: 30,70 + :delim: ; + :header-rows: 1 -Demo Artifacts (HEAT Templates) -------------------------------- +The demo artifacts are pushed to https://nexus.onap.org/content/repositories/releases/org/onap/demo/vnf -Version: 1.6.0 -.............. -:Release Date: 2020-06-15 +Use Cases and Requirements +-------------------------- -https://nexus.onap.org/content/repositories/releases/org/onap/demo/vnf/ +See dedicated :ref:`Kohn Use Cases and requirements page <docs_usecases_release>` -**New Features** +Maturity Testing Notes +---------------------- -* Update POM and heat env to use 1.6.0 -* Helm chart for visualization operator -* bug fixes -* Robot enhancements for various use cases +:ref:`Maturity testing page <integration-s3p>` -Robot Test Suites ------------------ +Open JIRAs/Known issues +----------------------- -Version: 1.6.3 +Integration +........... -:Release Date: 2020-06-03 -:sha1: 8f4f6f64eb4626433e6f32eeb146a71d3c840935 +`Integration JIRA page <https://jira.onap.org/issues/?jql=project%20%3D%20Integration%20>`_ -**New Features** +Testsuite +......... -- bug Fixes(Teardown, control loop, alotteed properties) -- CI support for hvves, 5GBulkPm and pnf-registrate +`Testsuite JIRA page <https://jira.onap.org/issues/?jql=project%20%3D%20Test>`_ diff --git a/docs/requirements-docs.txt b/docs/requirements-docs.txt index b3188ddd3..097282b97 100644 --- a/docs/requirements-docs.txt +++ b/docs/requirements-docs.txt @@ -1,15 +1,8 @@ -tox -Sphinx -doc8 -docutils -setuptools -six -sphinx_rtd_theme>=0.4.3 -sphinxcontrib-blockdiag -sphinxcontrib-needs>=0.2.3 -sphinxcontrib-nwdiag -sphinxcontrib-seqdiag +sphinx>=4.2.0 # BSD +sphinx-rtd-theme>=1.0.0 # MIT +sphinxcontrib-blockdiag # BSD +sphinxcontrib-seqdiag # BSD sphinxcontrib-swaggerdoc +sphinxcontrib-spelling sphinxcontrib-plantuml -sphinx_bootstrap_theme -lfdocs-conf +six diff --git a/docs/schema-update-apis.csv b/docs/schema-update-apis.csv new file mode 100644 index 000000000..391615363 --- /dev/null +++ b/docs/schema-update-apis.csv @@ -0,0 +1,49 @@ +API,Service level workflow retrieving API,Service level workflow execution API +Name,RetrieveServiceLevelWorkflow,ExecuteServiceLevelWorkflow +Type,Get,Post +URL,/onap/so/infra/workflowSpecifications/v1/workflows?resourceTarget=service,/onap/so/infra/instanceManagement/v1/serviceInstances/{serviceInstanceId}/workflows/{workflow_UUID} +Request,"Headers: application/json + +Path parameters: resourceTarget=service + +Body={ + +} + + + +","Headers: application/json + +Path parameters: serviceInstances; workflow_UUID + +Body={ + + ""modelInfo"":{ #targetServiceModelVersionId + + ""modelType"":""service"", + + ""modelInvariantUuid"":""fe41489e-1563-46a3-b90a-1db629e4375b"", + + ""modelVersionId"" : ""cd4decf6-4f27-4775-9561-0e683ed43635"", + + ""modelVersion"":""1.0"" + + } + +}" +Response,"200 – Successful retrieval of workflows + +400 - Bad Request + +500 - Internal Server Error + + + + +","202 - Request has been accepted for processing + +400 - Bad Request + +500 - Internal Server Error" +,, +,, diff --git a/docs/simulators/nf_simulator.rst b/docs/simulators/nf_simulator.rst new file mode 100644 index 000000000..64a6ac3b5 --- /dev/null +++ b/docs/simulators/nf_simulator.rst @@ -0,0 +1,148 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 +.. International License. http://creativecommons.org/licenses/by/4.0 + +.. _nf_simulator: + +:orphan: + +NF Simulator +============ + +Description +----------- +An idea behind NF (Network Function) Simulator is to introduce simulator, which supports ORAN defined O1 interface (reporting of NF events to Service Management Orchestrators). +Within the use-case, it is expected, that an NF configuration change, happening due to multiple reasons (network mechanism triggered change - e.g. discovery of neighbours) is reported to the network management system, using ONAP`s VES REST events. +The simulator is expected to cover planned NF behaviour - receive the config change via a NetConf protocol and report that change (also potentially other related changes) to the network management system using ONAP`s VES event. + +|image1| + +**Figure 1. Architecture Overview** + +1. NF Simulator code is stored in https://github.com/onap/integration-simulators-nf-simulator and all it's sub repos are: + + - for VES Client - https://github.com/onap/integration-simulators-nf-simulator-ves-client + - for Netconf Server - https://github.com/onap/integration-simulators-nf-simulator-netconf-server + - for AVCN Manager - https://github.com/onap/integration-simulators-nf-simulator-avcn-manager + - for PM HTTPS Server - https://github.com/onap/integration-simulators-nf-simulator-pm-https-server + +2. For above components have been prepared: + + - docker images in ONAP Nexus: + + - VES Client image - nexus3.onap.org:10001/onap/org.onap.integration.nfsimulator.vesclient + - AVCN Manager image - nexus3.onap.org:10001/onap/org.onap.integration.nfsimulator.avcnmanager + - PM HTTPS Server image - nexus3.onap.org:10001/onap/org.onap.integration.nfsimulator.pmhttpsserver + - Netconf Server images - nexus3.onap.org:10001/onap/org.onap.integration.nfsimulator.netconfserver + + - example helm charts: + + - `Helm charts <https://github.com/onap/integration-simulators-nf-simulator/tree/master/helm>`_ + +**VES Client, Netconf Server and PM HTTPS Server can be used and deployed separately depending on needs.** + +Only AVCN Manger connects VES Client with Netconf Server in order to support O1 interface. + +1. VES Client: +-------------- + +1. Purpose of VES Client + + Application that generates VES events on demand. + +2. What does it do? + + - Support both basic auth and TLS CMPv2 method of authentication. + - Allow to turn on and turn off hostname, verification in SSL. + - Allow to send one-time event and periodic events, based on event templates. + - Expose API to manage VES Client + - Provide template mechanism (Template is a draft event. Merging event with patch will result in valid VES event. + Template itself should be a correct VES event as well as valid json object. ) + - Patching - User is able to provide patch in request, which will be merged into template. + - Simulator support corresponding keywords in templates: RandomInteger(start,end), RandomPrimitiveInteger(start,end), RandomInteger, + RandomString(length), RandomString, Timestamp, TimestampPrimitive, Increment + - In place variables support - Simulator supports dynamic keywords e.g. #dN to automatically substitute selected phrases in defined json schema. + - Logging - Every start of simulator will generate new logs that can be found in docker ves-client container. + - Swagger - Detailed view of simulator REST API is available via Swagger UI + - History - User is able to view events history. + +2. Netconf Server: +------------------ + +1. Purpose of Netconf Server + + This server uses sysrepo to simulate network configuration. + It is based on sysrepo-netopeer2 image. + +2. What does it do? + + Server allows to: + + - Install custom configuration models on start up. + - Change configuration of that modules on runtime. + - Use TLS custom certificates + - Configure change subscription for particular YANG modules (Netconf server image run python application on the startup.) + - Manage netconf server using REST interface, with endpoints: + + - GET /healthcheck returns 200 "UP" if server is up and running + - POST /readiness return 200 "Ready" if server is ready, if not, returns 503 "Not Ready" + - POST /change_config/<path:module_name> changes configuration ad returns 202 "Accepted" + - GET /change_history returns 200 and change history as json + - GET /get_config/<path:module_name> returns 200 and current configuration + +3. AVCN Manager: +---------------- + +1. Purpose of AVCN Manager + + Manager that fetch changes of configuration from kafka and sends them to VES client. + +2. What does it do? + + The manager process notifications from NETCONF server. It does this by being a subscriber of a Kafka topic that is fed with NETCONF notifications. Incoming notifications are then processed and output of this processing is sent to VES client. + +4. PM HTTPS Server: +------------------- + +1. Purpose of PM HTTPS Server + + Server that is used in Bulk PM usecase over HTTPS + +2. What does it do? + + - Support TLS (CMPv2) method of authentication (used during connection to Data File Collector) + - Allow to use custom certificates + - Expose REST API in order to manage PM files stored in HTTPS server + + +Guides +====== + +User And Developer Guide +------------------------ +1. User guides: + + - `VES Client user guide. <https://github.com/onap/integration-simulators-nf-simulator-ves-client/blob/master/README.md>`_ + - `AVCN Manager user guide. <https://github.com/onap/integration-simulators-nf-simulator-avcn-manager/blob/master/README.md>`_ + - `PM HTTPS Server user guide. <https://github.com/onap/integration-simulators-nf-simulator-pm-https-server/blob/master/README.md>`_ + - `Netconf Server user guide. <https://github.com/onap/integration-simulators-nf-simulator-netconf-server/blob/master/README.md>`_ + - `Netconf Notification Application user guide. <https://github.com/onap/integration-simulators-nf-simulator-netconf-server/blob/master/src/python/README.md>`_ + - `NF Simulator CLI user guide <https://github.com/onap/integration-simulators-nf-simulator/blob/master/simulator-cli/README.md>`_ + +2. Jenkins builds: + + - `VES Client jenkins builds <https://jenkins.onap.org/view/integration-simulators-nf-simulator-avcn-manager/>`_ + - `AVCN Manager jenkins builds <https://jenkins.onap.org/view/integration-simulators-nf-simulator-netconf-server/>`_ + - `PM HTTPS Server jenkins builds <https://jenkins.onap.org/view/integration-simulators-nf-simulator-pm-https-server/>`_ + - `Netconf Server jenkins builds <https://jenkins.onap.org/view/integration-simulators-nf-simulator-ves-client/>`_ + +3. NF Simulator CSIT test cases: + + - `Project integration-simulators-nf-simulator-netconf-server-master-verify-csit-testsuites <https://jenkins.onap.org/view/integration-simulators-nf-simulator-netconf-server/job/integration-simulators-nf-simulator-netconf-server-master-verify-csit-testsuites/>`_ + - `Project integration-simulators-nf-simulator-netconf-server-master-csit-testsuites <https://jenkins.onap.org/view/integration-simulators-nf-simulator-netconf-server/job/integration-simulators-nf-simulator-netconf-server-master-csit-testsuites/>`_ + +4. NF Simulator sanity checks: + + - https://github.com/onap/integration-simulators-nf-simulator/tree/master/sanitycheck + +.. |image1| image:: ../files/simulators/NF-Simulator.png + :width: 10in
\ No newline at end of file diff --git a/docs/tox.ini b/docs/tox.ini index edac8c35f..46075fa6a 100644 --- a/docs/tox.ini +++ b/docs/tox.ini @@ -1,22 +1,31 @@ [tox] minversion = 1.6 -envlist = docs, +envlist = docs,docs-linkcheck,docs-spellcheck skipsdist = true [testenv:docs] -basepython = python3 -deps = -r{toxinidir}/requirements-docs.txt +basepython = python3.8 +deps = + -r{toxinidir}/requirements-docs.txt + -chttps://releases.openstack.org/constraints/upper/yoga + -chttps://git.onap.org/doc/plain/etc/upper-constraints.onap.txt?h=master commands = - sphinx-build -b html -n -d {envtmpdir}/doctrees ./ {toxinidir}/_build/html - echo "Generated docs available in {toxinidir}/_build/html" -whitelist_externals = - echo - git - sh + sphinx-build -W -q -b html -n -d {envtmpdir}/doctrees {toxinidir} {toxinidir}/_build/html [testenv:docs-linkcheck] -basepython = python3 -#deps = -r{toxinidir}/requirements-docs.txt -commands = echo "Link Checking not enforced" -#commands = sphinx-build -b linkcheck -d {envtmpdir}/doctrees ./ {toxinidir}/_build/linkcheck -whitelist_externals = echo +basepython = python3.8 +deps = + -r{toxinidir}/requirements-docs.txt + -chttps://releases.openstack.org/constraints/upper/yoga + -chttps://git.onap.org/doc/plain/etc/upper-constraints.onap.txt?h=master +commands = + sphinx-build -W -q -b linkcheck -d {envtmpdir}/doctrees {toxinidir} {toxinidir}/_build/linkcheck + +[testenv:docs-spellcheck] +basepython = python3.8 +deps = + -r{toxinidir}/requirements-docs.txt + -chttps://releases.openstack.org/constraints/upper/yoga + -chttps://git.onap.org/doc/plain/etc/upper-constraints.onap.txt?h=master +commands = + sphinx-build -W -q -b spelling -d {envtmpdir}/doctrees {toxinidir} {toxinidir}/_build/spellcheck diff --git a/docs/usecases-deprecated.csv b/docs/usecases-deprecated.csv deleted file mode 100644 index e7a5250e7..000000000 --- a/docs/usecases-deprecated.csv +++ /dev/null @@ -1,5 +0,0 @@ -Use Case,Link,Last Valid Version, Comments -vCPE Use Case,:ref:`link <docs_vcpe>` ,El Alto, No resources to test on Frankfurt -vIPsec with HPA Use Case ,:ref:`link<docs_vipsec_hpa>` ,El Alto, No resources to test on Frankfurt -Change Management Schedule Optimization,:ref:`link<docs_CM_schedule_optimizer>` ,El Alto, No resources to test on Frankfurt -Change Management Flexible Designer and Orchestrator ,:ref:`link<docs_CM_flexible_designer_orchestrator>` ,El Alto, No resources to test on Frankfurt diff --git a/docs/usecases.csv b/docs/usecases.csv deleted file mode 100644 index 920c1251e..000000000 --- a/docs/usecases.csv +++ /dev/null @@ -1,13 +0,0 @@ -Use Case,Link,Contacts -vFirewall with closed loop,:ref:`official doc <docs_vfw>` ,M.Platania B.Freeman -vFirewall/vDNS with HPA ,:ref:`official doc <docs_vfw_hpa>`,E.Multanen -vFirewall In-Place Software Upgrade with Traffic Distribution,:ref:`official doc <docs_vfw_traffic>`,L.Rajewski -vFirewall CNF With CDS,:ref:`official doc <docs_vFW_CNF_CDS>`,K.Bańka L.Rajewski -Scale Out,:ref:`official doc <docs_scaleout>`,M.Platania S.Blandford -CCVPN-E LINE over OTN NNI,:ref:`official doc <docs_ccvpn>`,G.Agrawal -CCVPN - MDONS ,:ref:`official doc <docs_CCVPN>`,X.Miao -BBS (Broadband Service),:ref:`official doc <docs_bbs>`,D.Perez Caparros D.Balsiger -vFirewall CNF with multicloud k8s plugin,:ref:`official doc <docs_vfw_edgex_multicloud_k8s>`,E.Multanen R.Sood -EdgeXFoundry CNF with multicloud k8s plugin,:ref:`official doc <docs_vfw_edgex_multicloud_k8s>`,E.Multanen -vCPE with Tosca,:ref:`official doc <docs_vcpe_tosca_local>`, H.Haibin L.Zhao -E2E Automation vLB with CDS,`wiki page <https://wiki.onap.org/pages/viewpage.action?pageId=71838891>`__,A.Seaudi Y.Malakov diff --git a/docs/usecases/deprecated_usecases.rst b/docs/usecases/deprecated_usecases.rst new file mode 100644 index 000000000..6d82140db --- /dev/null +++ b/docs/usecases/deprecated_usecases.rst @@ -0,0 +1,28 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 + International License. http://creativecommons.org/licenses/by/4.0 + +.. _deprecated_usecases: + +:orphan: + +Deprecated Use Cases and Functional Requirements +================================================ + +Each ONAP release deals with lots of use cases and functional requirements. +When possible, it is strongly recommended to automate the use cases. +In this case Integration team can take over the maintenance part of the use case. +If not automated, the use cases are fully under the responsibility of the use +case team and usually valid for the release the team was involved in. +However, these use cases, their artifacts remain in the repository. +Anyone can give a try even if the use cases are no more supported. + +This section deals with such use cases. +These use cases have been part of one release but have not been tested on the +last releases. They might fully deprecated or usable through minor adaptations. +The entry points are the use case owners. + +.. csv-table:: deprecated use case table + :file: ../files/csv/usecases-deprecated.csv + :widths: 50,20,10,20 + :header-rows: 1 + :delim: ; diff --git a/docs/usecases/release_automated_usecases.rst b/docs/usecases/release_automated_usecases.rst new file mode 100644 index 000000000..932a0d4f3 --- /dev/null +++ b/docs/usecases/release_automated_usecases.rst @@ -0,0 +1,37 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 + International License. http://creativecommons.org/licenses/by/4.0 + +.. _release_automated_usecases: + +:orphan: + +Automated Use Cases +------------------- + +These use cases have been run on the Daily CI chains and are used to +validate the integration of any new dockers in OOM. +New tests are indicated in **bold**. + +.. csv-table:: Infrastructure Healthcheck Tests + :file: ../files/csv/tests-infrastructure-healthcheck.csv + :widths: 20,40,20,20 + :delim: ; + :header-rows: 1 + +.. csv-table:: Healthcheck Tests + :file: ../files/csv/tests-healthcheck.csv + :widths: 20,40,20,20 + :delim: ; + :header-rows: 1 + +.. csv-table:: Smoke Tests + :file: ../files/csv/tests-smoke.csv + :widths: 20,40,20,20 + :delim: ; + :header-rows: 1 + +.. csv-table:: Security Tests + :file: ../files/csv/tests-security.csv + :widths: 20,40,20,20 + :delim: ; + :header-rows: 1 diff --git a/docs/usecases/release_non_functional_requirements.rst b/docs/usecases/release_non_functional_requirements.rst new file mode 100644 index 000000000..b3f5a0b54 --- /dev/null +++ b/docs/usecases/release_non_functional_requirements.rst @@ -0,0 +1,15 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 + International License. http://creativecommons.org/licenses/by/4.0 + +.. _release_non_functional_requirements: + +:orphan: + +Non Functional Requirements +---------------------------- + +.. csv-table:: non functional requirements table + :file: ../files/csv/usecases-non-functional-requirements.csv + :widths: 5,45,12,38 + :delim: ; + :header-rows: 1 diff --git a/docs/usecases/release_requirements.rst b/docs/usecases/release_requirements.rst new file mode 100644 index 000000000..0ec4b1b95 --- /dev/null +++ b/docs/usecases/release_requirements.rst @@ -0,0 +1,15 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 + International License. http://creativecommons.org/licenses/by/4.0 + +.. _release_requirements: + +:orphan: + +Functional Requirements +----------------------- + +.. csv-table:: functional requirements table + :file: ../files/csv/usecases-functional-requirements.csv + :widths: 5,45,12,38 + :delim: ; + :header-rows: 1 diff --git a/docs/usecases/release_usecases.rst b/docs/usecases/release_usecases.rst new file mode 100644 index 000000000..749c4483a --- /dev/null +++ b/docs/usecases/release_usecases.rst @@ -0,0 +1,37 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 + International License. http://creativecommons.org/licenses/by/4.0 + +.. _release_usecases: + +:orphan: + +Kohn Use Cases +============== + +Description +----------- + +This session includes use cases and functional requirements which have been +officially verified in Kohn release by the ONAP community. + +For each use case or functional requirement, you can find contact names and a +link to the associated documentation. + +This documentation deals with + + 1. What has been implemented + 2. Step by step instructions to deploy and execute the tests, including the + links to download the related assets and resources + 3. Known issues and workarounds + +Use cases +--------- + +Kohn Official Use Cases +~~~~~~~~~~~~~~~~~~~~~~~ + +.. csv-table:: + :file: ../files/csv/usecases.csv + :widths: 10,40,20,30 + :delim: ; + :header-rows: 1 |
