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:

STEPS for Testing:

Step 0 (pre-conditions for testing):

DMaaP is up and running
SDNC is up and running
- Installed ansible playbooks for precheck, upgrade, postcheck on SDNC
- Installed DGs to SDNC for the NB API of SDNC about lifecycle management (need links to SDNC API here)
EM and PNF emulators are up and running at manually assigned IP addresses and ports (eventually PNF PnP use case emulator and this emulator should be merged to have a full picture)
Test script is up and running (should be able to pub/sub to DMaaP)
- Q: Is this homed at SO or as a separate test module?

Step 1:

Test script runs sequentially
- pre-check API
- S/W upgrade API
- post-check API
API payload

Links to JIRA Items for Casablanca:

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