Description

PNF Software upgrade includes:

Support in-place software upgrade for PNF.
Define generic building blocks, which can be used for workflow design in the design time.
Identify gaps and amend ONAP components to support different flows for software management and configuration (e.g., with/without external controller, different ONAP controller options, different adaptors in ONAP controllers).
Support External Controller (e.g., EMS) as the main entity responsible for carrying out the detailed vendor-specific software upgrade steps.
Enhance precheck and postcheck steps in the upgrade process by vendor-specific rules. Define procedures involved in the design time and run time for specifying these rules.
Enhance PNF modeling needed for PNF software upgrades (e.g., expected software version) and define processes in ONAP components (e.g., SO, A&AI, DCAE, and ONAP Controllers) for successful/unsuccessful software upgrades.
Demonstrate single PNF upgrade and batch upgrade.

Presentations:

PNF Software upgrade flow to be tested for Casablanca:

Bold items on the right will be tested (steps 6, 7, 10, 12, 14, 15).

Overall Process for Casablanca:

PNF upgrade process in Casablanca will follow the similar procedures used for VNF in-place upgrade in Beijing. Main differences:
- Extended payload parameters for PNF in NB API for SDNC (e.g., PNF Identifier, PNF specific rules, External Controller info)
- PNF specific DG branches that are processed based on the presence of PNF specific parameters
- Ansible adaptor that accepts External Controller end point as a parameter from API calls on interface 6.
- External controller that executes playbooks received from ansible adaptor.

Links to JIRA Items:

Q&A:

Why not netconf?
- For Casablanca, we are utilizing most of the workflows already exist in VNF in place upgrade. Eventually, netconf support will/might be needed.
What happens if upgrade fails due to PNF, EM or even SDNC?
- A rollback mechanism should be defined. Depending on where the failure is occurring, how to detect it, how to rollback and how to communicate the rollback (e.g., during failure or post-recovery) need more detailed analysis.
Why doesn't ONAP (i.e., SDN controller) directly handle PNF configuration and upgrades?
- There are too many complexities potentially involved in 5G PNF upgrades. EMS simplifies the processes in ONAP substantially and allows for easier adoption.
- We plan to support various options including with External Controller, without External Controller, hybrid (e.g., some workflows with direct PNF access, some workflows with External Controller).

#	Test Case Description	Test Status
1 EC registration test	Ensure ONAP controller can find out the EC	NOT TESTED
2 PreCheck test	Ensure the EC can receive the precheck command from ONAP controller	NOT TESTED
3 SwUpgrade test	Ensure the EC can receive the software upgrade command from ONAP controller	NOT TESTED
4 PostCheck test	Ensure the EC can receive the postcheck command from ONAP controller	NOT TESTED
5 New SW version report test	Ensure the software upgrade completion event can be reported to DCAE	NOT TESTED
6 New SW version update test	Ensure the new software version can be updated in A&AI	NOT TESTED
7 E2E Workflow execution test	Ensure the e2e software upgrade workflow can be executed at run time	NOT TESTED