aboutsummaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/docs_5G_PNF_Software_Upgrade.rst80
-rw-r--r--docs/docs_5G_PNF_Software_Upgrade_direct_netconf_yang.rst36
-rw-r--r--docs/files/softwareUpgrade/APIDecisionTree.pngbin0 -> 54629 bytes
-rw-r--r--docs/files/softwareUpgrade/DirectNetconfYangInterface.pngbin0 -> 22980 bytes
-rw-r--r--docs/files/softwareUpgrade/SWUPWorkflow.pngbin0 -> 79409 bytes
5 files changed, 75 insertions, 41 deletions
diff --git a/docs/docs_5G_PNF_Software_Upgrade.rst b/docs/docs_5G_PNF_Software_Upgrade.rst
index 0424a3116..fd078e2da 100644
--- a/docs/docs_5G_PNF_Software_Upgrade.rst
+++ b/docs/docs_5G_PNF_Software_Upgrade.rst
@@ -1,60 +1,58 @@
-.. This work is licensed under a Creative Commons Attribution 4.0
- International License. http://creativecommons.org/licenses/by/4.0
-
+.. 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:
+============================================================
5G PNF Software Upgrade
-----------------------------
+============================================================
Description
-~~~~~~~~~~~
-The 5G PNF Software upgrade use case shows how users/network operators can modify the software of PNF instance during installation or regular maintaince. This use case is one aspect of Software Management. This could be used to update the PNF software to a newer or older version of software.
+------------
+
+The 5G PNF Software upgrade use case shows how users/network operators can modify the software of a PNF instance during installation or regular maintenance. This use case is one aspect of Software Management. This could be used to update the PNF software to a different version of software.
+
+Useful Link
+------------
+
+`PNF Software Upgrade Wiki Page <https://wiki.onap.org/display/DW/PNF+software+upgrade+in+R6+Frankfurt>`_
+
+
+Current Status in Frankfurt
+---------------------------
+============================================================
+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>`_
-**Useful Links**
-- `5G - PNF software upgrade use case documentation <https://wiki.onap.org/pages/viewpage.action?pageId=40206496>`_
-- `5G - PNF software upgrade Integration test case status for Dublin release <https://wiki.onap.org/display/DW/5G+-+PNF+SW+Upgrade+-+Integration+Test+Cases>`_
+ - (https://wiki.onap.org/pages/viewpage.action?pageId=64007309)
-**Current status in Dublin**
-- with the support of an EM
-- LCM API (focus on controller only)
-- integration of basic 3GPP SwM interfaces (*)
-- ansible protocol only
-Note: In Dublin, Controller provided four related APIs (precheck, postcheck, upgrade and rollback), which were finally translated to invoke interfaces provided by EM. Rollback API is to call swFallback operation, and Upgrade API is to call downloadNESw, installNESw and activateNESw operations (Ref. 3GPP TS 32.532[1]).
+* `Using Ansible protocol with EM <docs_5g_pnf_software_upgrade_ansible_with_EM>`_
-**Future Plans**
-- E2E PNF Software upgrade both for design and runtime
-- Generic workflow for demonstration
+ - (https://wiki.onap.org/pages/viewpage.action?pageId=64007357)
-How to Use
-~~~~~~~~~~
-Upgrading PNF (instance) software requires the user/network operator to trigger the upgrade operation from the UI, e.g. VID or UUI. In Dublin, users need use ONAP Controllers GUI or publish DMaaP messages to trigger the LCM opeations, which are pre-check, post-check, upgrade and rollback. After receiving the API requests, the ONAP controllers will communicate to EMS through south-bound adaptors, which is Ansible protocol only in Dublin.
+* `Using Netconf/Yang interface with EM <docs_5g_pnf_software_upgrade_netconf_with_EM>`_
-Note that, both APPC and SDNC in R4 supported Ansible. Taking SDNC and Prechecking as an example, the steps are as follows:
+ - (https://wiki.onap.org/pages/viewpage.action?pageId=64008675)
-1) `In ansible server container, prepare the ssh connection conditions to the external controller, both ssh key file and ansible inventory configuration`_
+Common tasks for all scenarios
+------------------------------
-2) `In sdnc controller container, update the dg configuration file: lcm-dg.properties.`_
+SO Workflows
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-For example:
-::
-lcm.pnf.upgrade-pre-check.playbookname=ansible_huawei_precheck
-lcm.pnf.upgrade-post-check.playbookname=ansible_huawei_postcheck
-lcm.pnf.upgrade-software.playbookname=ansible_huawei_upgrade
-lcm.pnf.upgrade-rollback.playbookname=ansible_huawei_rollback
+Common SO workflows are used with generic SO building blocks which can be used for any PNF software upgrade scenarios. In Frankfurt release, a PNF software upgrade workflow and a PNF preparation workflow have been created.
-3) `Login controller UI, access the pre-check LCM operation (or other operations) and send request, the detailed request parameters can be found in corresponding test case link.`_
+ .. image:: files/softwareUpgrade/SWUPWorkflow.png
-4) `The HTTP API response code 200 and LCM retured code 400 (See APPC return code design specification) indicate success, otherwise failed.`_
+LCM evolution with API Decision Tree
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Test Status and Plans
-~~~~~~~~~~~~~~~~~~~~~
-To see information on the status of the test case: https://wiki.onap.org/display/DW/5G+-+PNF+SW+Upgrade+-+Integration+Test+Cases
+A decision point has been introduced in the Frankfurt release. The service designer needs to indicate which LCM API they would like to use for the LCM operations on the selected PNF source at design time (via SDC). The possible LCM APIs are: SO-REF-DATA (default), CDS, SDNC, or APPC.
-References
-==========
-[1] TS 32.532,Telecommunication management; Software management (SwM); Integration Reference Point (IRP); Information Service (IS)
+ .. image:: files/softwareUpgrade/APIDecisionTree.png
-Known Issues and Resolutions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-None
diff --git a/docs/docs_5G_PNF_Software_Upgrade_direct_netconf_yang.rst b/docs/docs_5G_PNF_Software_Upgrade_direct_netconf_yang.rst
new file mode 100644
index 000000000..f2d4db1a4
--- /dev/null
+++ b/docs/docs_5G_PNF_Software_Upgrade_direct_netconf_yang.rst
@@ -0,0 +1,36 @@
+.. 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_direct_netconf_yang:
+
+===========================================================================
+PNF Software Upgrade Scenario: Using Direct Netconf/Yang interface with PNF
+===========================================================================
+Software Upgrade Procedure
+------------------------------------
+
+With this scenario, the pre-conditions are:
+
+* SO PNF software upgrade workflows are ready to use
+* An SDC service template with one PNF resource has been designed (including CBA association) and has been distributed
+* Service instantiation is completed, including PNF PnP. meaning a PNF instance is in operation with connectivity between PNF-ONAP, PNF-SFTP
+* At design time, the CONTROLLER_ACTOR is set for CDS client for the API selection decision
+* PNF has direct NETCONF/YANG interface configured which can be reachable from ONAP controller.
+
+At run time, the PNF in-place software upgrade procedure is triggered when the operator provides the selected PNF software upgrade workflow, a PNF instance, and the target software version using VID GUI or CLI.
+Then the software upgrade workflow is executed in SO:
+
+a. SO sends CDS request(s) with action-identifier {actionName, blueprintName, blueprintVersion} to the blueprint processor inside the controller using CDS self-service API
+b. Controller/blueprint processor executes the blueprint scripts including sending NETCONF request(s) to the PNF instance via the direct NETCONF interface.
+c. Repeat above two steps for each SO building blocks.
+
+ .. image:: files/softwareUpgrade/DirectNetconfYangInterface.png
+
+
+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/files/softwareUpgrade/APIDecisionTree.png b/docs/files/softwareUpgrade/APIDecisionTree.png
new file mode 100644
index 000000000..dff8d38fd
--- /dev/null
+++ b/docs/files/softwareUpgrade/APIDecisionTree.png
Binary files differ
diff --git a/docs/files/softwareUpgrade/DirectNetconfYangInterface.png b/docs/files/softwareUpgrade/DirectNetconfYangInterface.png
new file mode 100644
index 000000000..4da660793
--- /dev/null
+++ b/docs/files/softwareUpgrade/DirectNetconfYangInterface.png
Binary files differ
diff --git a/docs/files/softwareUpgrade/SWUPWorkflow.png b/docs/files/softwareUpgrade/SWUPWorkflow.png
new file mode 100644
index 000000000..6455a5ac9
--- /dev/null
+++ b/docs/files/softwareUpgrade/SWUPWorkflow.png
Binary files differ