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.
Questions:
- 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 cases and status
| # | 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 |