diff options
| -rw-r--r-- | docs/docs_5G_PNF_Software_Upgrade_ansible_with_EM.rst | 29 | ||||
| -rw-r--r-- | docs/docs_5G_PNF_Software_Upgrade_netconf_with_EM.rst | 29 |
2 files changed, 54 insertions, 4 deletions
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 2c9ff294e..1482cb5d6 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,31 @@ .. _docs_5g_pnf_software_upgrade_ansible_with_EM: -=========================================================================== PNF Software Upgrade Scenario: Using Ansible protocol with EM -===========================================================================
\ No newline at end of file +------------------------------------------------------------- + +Software Upgrade Procedure +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +With this scenario, the pre-conditions are: + +* SO PNF software upgrade workflows are ready to use. For this scenario, the CONTROLLER_ACTOR is set for SDNC client for the API selection decision. +* Service instantiation is completed, including PNF PnP. It means a PNF instance is in operation and is avaibale for ONAP (maybe via EMS). +* ONAP Controller (SDNC and ansible server) and DMaaP are ready to use. It means necessary ansible connection and DMaaP topics are ready. +* EMS has direct ansible interface to the ansible server. The underlying protocol is SSH. + +At run time, the service provider in R6 can use CLI to trigger the PNF in-place software upgrade procedure by selecting the existing PNF software upgrade workflow or uploading a custom workflow, as well as an identifier of a PNF instance, the target software version and optional json-formatted payload. + +Then the software upgrade workflow is executed as follows: + +a. SO sends request(s) with input {action, action-identifiers, common header, and optional payload} to SDNC API handler using traditional LCM API. +b. SDNC API handler executes corresponding DG and sends requests to the ansible server. +c. The ansible server executes ansible playbook with the EMS. Then EMS is responsible of software upgrade procedure of the selected PNF instance. +d. Repeat above steps for each SO building block in the corresponding PNF software upgrade workflow. + +Test Status and Plans +~~~~~~~~~~~~~~~~~~~~~ + +To see information on the status of the test cases, please follow the link below: + +`Enhancement on PNF software upgrade using Ansible Test Status <https://wiki.onap.org/pages/viewpage.action?pageId=64007357#EnhancementonPNFS/WUpgradeusingAnsible-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 d80872f92..0d5b3b3a6 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,31 @@ .. _docs_5g_pnf_software_upgrade_netconf_with_EM: -=========================================================================== PNF Software Upgrade Scenario: Using Netconf/Yang interface with EM -===========================================================================
\ No newline at end of file +------------------------------------------------------------------- + +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. +* At design time, the CONTROLLER_ACTOR is set for CDS client for the API selection decision. +* EMS (with netconf capability and suitable software management yang model) is ready to use. It has direct NETCONF/YANG interface configured which can be reachable from CDS. + +At run time, the service provider in R6 can use CLI to trigger the PNF in-place software upgrade procedure by selecting the existing PNF software upgrade workflow or uploading a custom workflow, as well as an identifier of a PNF instance, the target software version. + +Then the software upgrade workflow is executed as follows: + +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 EMS via the direct NETCONF interface. Then EMS is responsible of software upgrade procedure of the selected PNF instance. +c. Repeat above two steps for each SO building block in the corresponding PNF software upgrade workflow. + +Test Status and Plans +~~~~~~~~~~~~~~~~~~~~~ + +To see information on the status of the test cases, please follow the link below: + +`PNF Software Upgrade with netconf/yang interface with EM Test Status <https://wiki.onap.org/pages/viewpage.action?pageId=64008675#PNFsoftwareupgradewithNetconf/YanginterfacewithhEM-TestStatus>`_ |