Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 88 Current »

Table of Contents

Key contact persons

Zu Qiang Lukasz Rajewski Ajay Mahimkar Chris Rapposelli-Manzo

BUSINESS DRIVERS

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. 

xNF software upgrade procedure

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.

xNF Software Upgrade without xNF artifacts updating in Release F

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 

  • There can be a mismatch between the functions running in the VNF/PNF instance and the management instance schema stored in the ONAP, after upgrade.
  • The mismatch includes not only the artifacts provided by the vendor, e.g. new CM Yang model, but also the artifacts provided at design time, e.g. CBA files from CDS.
  • Then ONAP is not aware of any of new functions supported by the new software, including new PM counters, new CM Yang model, new Alarms, new CBA, new scripts, new Helm chat, etc.
  • For the operator, it is difficult to make use of any new functions supported in the new software version.

xNF Software Upgrade with xNF artifacts updating in Release G

The following is the xNF software upgrade procedure with schema update. 

  1. A vendor shall provide
    1. a new VNF/PNF package with updated artifacts, and
    2. the new VNF/ PNF software image to the operator.
  2. At receiving of the new package, the operator shall
    1. onboard the new package and create a new resource template or update the existing resource template (PNF or VNF)
    2. update the existing service template with the new or updated resource template
    3. distribute the updated service template to run time. 
  3. At run time, the operator shall, based on the updated service template,
    1. upgrade a service instance and its resource instances, and
    2. update the AAI entry accordingly 

The above procedure is based on the following conditions:

  • When updating a service template at design time, the resource instance name and network topology shall be unchanged.
  • A service template must be upgradable from any previous versions, including that any new resource template of a given resource instance (within the service template) must be upgradeable from any previous resource template versions.
  • At run time, resource upgrade sequence is not sensitive in service instance upgrading procedure

Function limitations in Release G

  • The operator shall know the possible/feasible resource upgrade path based on vendor provided information.
  • When operator updating a service template, the updated service template must be upgradable from any previous versions:
    • Within the service template, the resource instance name and network topology are unchanged.
    • The new resource template of a given resource instance (within the service template) must be upgradeable from any previous resource template versions.

Note: This is to avoid adding possible upgrade paths info and upgrade sequence info into SDC model

Function descriptions

Update a xNF resource template from a new onboarding package

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.

Service level LCM workflow in SO

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:

  • Service Level Preparation
    • Creating resource template instance upgrade list by comparing the service templates
    • 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
  • Service Level Upgrade

    • 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

  • Service Level Update
    • Update the model-version-id of the service template in the A&AI entry
  • Service Level postCheck

    • 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:

Workflow view

New SO APIs

APIService 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

SO-2929 - Getting issue details... STATUS

SO-2930 - Getting issue details... STATUS

Interfaces between service workflow and resource workflow

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
Body: targetServiceModelVersionId

Ok or
not ok

SO-2927 - Getting issue details... STATUS

a generic VNF health check workflow

GenericVnfHealthCheck

vnfInstanceId

Ok or
not ok

SO-3192 - Getting issue details... STATUS

a generic PNF health check workflow

GenericPnfHealthCheck

Path parameters: serviceInstanceId, pnfInstanceId

Body: PNF_Name

Ok or
not ok

SO-3018 - Getting issue details... STATUS

a generic VNF software upgrade workflow

GenericVnfSoftwareUpgrade

[VNFinPlaceSoftwareUpdate]
name is under discussion

/onap/so/infra/serviceInstantiation/{version}/serviceInstances/{serviceInstanceId}/vnfs/{vnfInstanceId}/inPlaceSoftwareUpdate

Path parameters: serviceInstanceId, vnfInstanceId

Body: new_software_version, existing_software_version

Ok or
not ok

SO-2952 - Getting issue details... STATUS


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
not ok

SO-2515 - Getting issue details... STATUS

Impact Details

Summary

PROJECTPTLUser Story / EpicRequirement
SDC

Ofir Sonsino

  • Bug fixing at updating a resource template based on a new onboarding package

A&AI
James Forsyth
  • Add software-version attribute on Generic-VNF object level

SO

Seshu Kumar Mudiganti

  • Generic service level upgrade workflow
  • New SO building block to enable service level LCM operation including update A&AI, new service level LCM BB, etc.
  • Service level workflow retrieving API
  • Service level workflow execution API
  • In-Place VNF Upgrade workflow with ControllerExecutionBB
  • Update of VNF software-version attribute in A&AI

Integration
Morgan Richomme
  • test cases for resource template updating
  • test cases for new SO APIs
  • test cases for service level workflow execution
  • test cases for e2e service level upgrade procedure (with PNF simulator)
  • test cases for e2e service level upgrade procedure (vFW or vLB/DNS use case with CDS)
  • Documentation updates  

List of PTLs: Approved Projects

Requirement Status

key summary created assignee reporter priority arch review m1 scorecard m1 approval m2/3 scorecard m2/3 approval m4 scorecard m4 approval rc0 scorecard rc0 approval status tsc priority
Refresh

Development Status

key summary type created updated assignee reporter priority status resolution subtasks fixversions
Refresh

Test Status :  E2E Test Case PNF-Software Upgrade With Schema Updates

1There should be a test case for each item in the sequence diagram

NOT YET TESTED

2create additional requirements as needed for each discreet step

COMPLETE

3Test cases should cover entire Use Case

PARTIALLY COMPLETE

4 Test Cases should include enough detail for testing team to implement the test

 FAILED

Discussion Materials

This section is to review slides for discussion.


Meeting Notes/Discussions

  • No labels