Zu Qiang (Ericsson) Lukasz Rajewski Ajay Mahimkar Chris Rapposelli-Manzo
Executive Summary: A schema update in relation to a xNF software upgrades is a routine for network upgrade to support new xNF features, improve efficiency or increase xNF capacity on the field, and to eliminate bugs. This use case provides to ONAP an advantage in orchestrating and managing the Life Cycle of a Network Services in-line with business and service objectives.
Business Impact: Deployment and orchestration of new services over CNFs, VNFs and PNFs in a model and software driven way simplifies the network management. Enables operators and service providers to manage the Life Cycle of a Network Service. Assuring continuity of operation of services is crucial for production and carrier grade environments. The actualization or upgrades of software and in consequence required changes in the service model is a natural part of service instance life cycle. Without the support of ONAP service update with schema change, service life cycle management by ONAP can be very difficult which can impact the quality and continuity of services.
Business Markets: All operators and service providers that are using ONAP for service and network function Life Cycle Management
Funding/Financial Impacts: Reduction in operations expense from using industry standard Interfaces.
Organization Mgmt, Sales Strategies: There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider.
Note: The descriptor and artifacts information included in the resource and service template are named as schema in this project. The procedure of updating the resource / service template info, i.e. descriptor and artifacts, is named as schema update in this project.
The current VNF in-place software upgrade procedure on a single VNF instance without schema updat is describe in Change Management Dublin Extensions.
The current PNF in-place software upgrade procedure on a single PNF instance without schema update
In all the above procedure, Vendor only delivers a new software image to the operator. There is no additional onboarding package which includes a descriptor and its artifacts of the new image. At run time, when the new software image is delivered to the operator, the software upgrade procedure may be triggered.
The current in-place software upgrade procedure is a good solution, if the new software version does not introduce any new functions. For instance, the new version only introduce some bug fixings.
However, with the above ONAP VNF/PNF in-place software upgrade procedure, only the software running in the instance is updated. The corresponding ONAP service / resource management object instances are unchanged. The consequence is that
The following is the xNF software upgrade procedure with schema update.
The above procedure is based on the following conditions:
Note: This is to avoid adding possible upgrade paths info and upgrade sequence info into SDC model
When updating a resource template from a new VSP casr, the new onboarded descriptor and the new onboarded artifacts will be transformed into the new version of the resource csar. The current resource name and invariantUUID will be remained.
As an alternative, a resource csar can be updated manually using SDC GUI.
The update path (green path in above picture) is supported in the current SDC implementation. However, there are bugs which need to be fixed.
A generic SO workflow is created which can be used to upgrade one service instance based on the updated service template. This service level workflow is network function type independent. When upgrade one resource instance, the subsequent resource level upgrade workflow is selected based on the network function type. It contains following main steps:
Select a resource level upgrade workflow based on the resource type
Execute the selected resource level upgrade workflow on each upgrading resource instances
Update the software version, model-invariant-id and model-version-id of the resource template in the A&AI entry at end of each Resource level upgrade workflow
Select a resource level health check workflow based on the resource type
Execute the selected resource level health check workflow on all resource instances within the service
The following is an example of the service level workflow with PNF upgrade sub-workflow is called at Service Level Upgrade step:
New SO APIs
API | Service level workflow retrieving API | Service level workflow execution API |
Name | RetrieveServiceLevelWorkflow | ExecuteServiceLevelWorkflow |
Type | Get | Post |
URL | /onap/so/infra/workflowSpecifications/v1/workflows?resourceTarget=service | /onap/so/infra/instanceManagement/v1/serviceInstances/{serviceInstanceId}/workflows/{workflow_UUID} |
Request | Headers: application/json Path parameters: resourceTarget=service Body={ } | Headers: application/json Path parameters: serviceInstances; workflow_UUID Body={ "modelInfo":{ #targetServiceModelVersionId "modelType":"service", "modelInvariantUuid":"fe41489e-1563-46a3-b90a-1db629e4375b", "modelVersionId" : "cd4decf6-4f27-4775-9561-0e683ed43635", "modelVersion":"1.0" } } |
Response | 200 – Successful retrieval of workflows 400 - Bad Request 500 - Internal Server Error | 202 - Request has been accepted for processing 400 - Bad Request 500 - Internal Server Error |
Jira |
workflows | Workflow Name | Inputs | Outputs | Jira |
a generic service level upgrade workflow | GenericServiceLevelUpgrade | /onap/so/infra/instanceManagement/v1/serviceInstances/{serviceInstanceId}/workflows/{workflow_UUID} Path parameters: serviceInstances; workflow_UUID | Ok or | |
a generic VNF health check workflow | GenericVnfHealthCheck | vnfInstanceId | Ok or | |
a generic PNF health check workflow | GenericPnfHealthCheck | Path parameters: serviceInstanceId, pnfInstanceId Body: PNF_Name | Ok or | |
a generic VNF software upgrade workflow | GenericVnfSoftwareUpgrade [VNFinPlaceSoftwareUpdate] | /onap/so/infra/serviceInstantiation/{version}/serviceInstances/{serviceInstanceId}/vnfs/{vnfInstanceId}/inPlaceSoftwareUpdate Path parameters: serviceInstanceId, vnfInstanceId Body: new_software_version, existing_software_version | Ok or | |
a generic PNF software upgrade workflow | GenericPnfSoftwareUpgrade | /onap/so/infra/instanceManagement/v1/serviceInstances/{serviceInstanceId}/pnfs/{pnfName}/workflows/{workflowUuid} Path parameters: serviceInstanceId, pnfInstanceName Body: target software version | Ok or |
PROJECT | PTL | User Story / Epic | Requirement |
SDC |
| ||
A&AI |
| ||
SO |
| ||
Integration |
|
List of PTLs: Approved Projects
1 | There should be a test case for each item in the sequence diagram | NOT YET TESTED |
2 | create additional requirements as needed for each discreet step | COMPLETE |
3 | Test cases should cover entire Use Case | PARTIALLY COMPLETE |
4 | Test Cases should include enough detail for testing team to implement the test | FAILED |
This section is to review slides for discussion.