Project Name:

  • Proposed name for the project: Network Function Change Management
  • Proposed name for the repository: NFCM

Project description:

  • Network Functions (NFs) like any software have to be updated periodically (to support new features, fix bugs, security holes, etc). However, complex dependencies, upgrade mechanisms, SLAs etc require that the upgrades or changes are managed carefully. For example, NFs may by upgraded in-place or through a scale out and replace mechanism. The change may require draining, redirection, or load-balancing of traffic. It may also involve multiple NFs whose changes need to be coordinated for service continuity. It will also require capabilities like A/B testing, pre- and post- change testing, scheduling, etc. This project, Network Function Change management, provides the capability to design, schedule and manage configuration changes and software upgrades of network functions managed by ONAP. This project exposes the existing capabilities of ONAP components (like that of the service orchestrator and the controller) to users to help them stitch workflows that use these capabilities for managing NF changes or upgrades.

Scope:

Since Change Management is an E2E platform function the focus for R1 will be to define the flows and ensure that ONAP components provide the Interfaces and data needed. 

  • This project provides users with the ability to design workflows based on a suite of existing capabilities exposed by other ONAP components. For example, a user can make calls to a controller to execute actions, to A&AI to get inventory status, and existing orchestration flows, and combine these calls to achieve a higher level orchestration function. SDC will be used for designing the workflows.
  • This project provides a capability to deploy (and undeploy) and upgrade the designed workflows to an execution environment (e.g., the service orchestrator). This assumes that the execution environment provides APIs to perform these functions.
  • This project provides runtime management (start, pause, resume, stop, rollback) and monitoring of the workflows.  This project provides a portal for a user to come in and manually control these workflows or monitor them or track the history of workflows that have been executed. Again we assume that the execution environment provides APIs to perform these functions. We also assume that other ONAP components (e.g., Policy) can trigger one of these workflows as part of a control loop action.
  • This project provides capabilities for scheduling workflows. The schedule could range across a subset of the instances of an NF, across instances of multiple NFs or combinations therein. For complex scheduling use cases we foresee the use of SNIRO Optimization Framework to be used as a home for specific scheduling optimization micro-services.
  • This project provides capabilities for selecting the type and instances of the NFs that need to be associated with the workflows (as well as for scheduling).
  • This project will document the best practices for End-to-End workflow design.


Beijing Release: We have reduced the functionality scope for Change Management in Beijing to execute a pre-defined workflow to carry out in-place software upgrade.

Other functionalities would be considered in subsequent ONAP releases.


Beijing Pair-wise testing status: [In-progress] SB-07 environment


Status update as of 31st May 2018 - 12:15 AM

SO - DMAAP - SDNC issues resolved. Fixes in APPC client library with SO working nicely. Tremendous team work !!!! Special thanks to Ruchira, Arthur, Brian, Marco, Elena, Kang, Dan, Jimmy, Rob, Randa, Ryan and Patrick.

Successfully tested the SO CM workflow end to end - pre-check, software upgrade and post-check went through successfully and the vGW instance was successfully upgraded.

Next to work with VID on request to SO (31st May morning!) - this is non-blocking for CM Beijing. VID provides a graphical user interface and the same workflow can also be invoked using SO (Which is tested successfully with vGW so far!)

Status update as of 30th May 2018 - 5:15 PM

Tremendous progress made on testing SO-SDNC using the APPC client library within SO. The issue under investigation was SO not able to publish SDNC event onto DMAAP. The cambria partition was null before. APPC and SO fixed the code to now set it correctly to SDNC. But now SDNC is working on fixing the code to correctly read the cambria partition (upper case instead of lower case). SDNC code deployed, but event not reaching DMAAP from SO.

Status update as of 23rd May 2018: Testing is in Progress

vGW (vCPE) is now successfully instantiated using ONAP and is thus available to test with Change Management workflow. A&AI has the vGW instance and SO can proceed with the in-place software upgrade workflow testing.

The key issue is SO being able to publish SDNC-LCM messages on DMAAP and receive the response from SDNC. The team is investigating and making very good progress on resolving issues (e.g., setting variables correctly such as cloudRegion)

1) SDN-C To Ansible and Ansible to VNF instance: INT-476 - Getting issue details... STATUS

Successfully completed by Dan Timoney.

Given the manual instantiation, Ruchira Agarwal is working on testing the Ansible playbook execution from SDN-C to Ansible server and Ansible Server to VNF instance (vG/vCPE).

IP address of vG is 10.12.5.85

2) SO to SDN-C: INT-475 - Getting issue details... STATUS

Issue currently with SO publishing on to DMAAP - Arthur Martella, Marco Platania, Brian Freeman, Ruchira Agarwal, Ajay Mahimkar, and Elena Kuleshov are actively working on troubleshooting & resolving the issue.

3) VID to SO: INT-474 - Getting issue details... STATUS

NF role is important to be set in order to have VID start the change workflow execution. Currently, it is not set as part of instantiation flow. A&AI to provide API to set the NF role - robot will use during instantiation.

issue is resolved: VNF instantiation is not working with R2 - vCPE is not instantiated in SB-07 using SO.

https://jira.onap.org/browse/SO-618

Resolution: Kang Xi manually instantiated vG/vCPE in SB-07 but the instance is not seen in A&AI due to which SO cannot proceed with the in-place software upgrade workflow. However, SDN-C is able to now test the Ansible playbook execution on the VNF instance.


Beijing Development Completed - Code Delivered

RequirementProjectPoint of contact (PTL)
StatusJIRA Tickets
Lock/unlock VNF instance A&AIJimmy Forysth jf2512@att.com

GREEN


Ansible code for in-place software upgrade vCPE / DemoEric Multanen eric.w.multanen@intel.com

GREEN

CCSDK-221 - Getting issue details... STATUS

Software upgrade executionSDN-CDan Timoneydt5972@att.com

GREEN

SDNC-278 - Getting issue details... STATUS

Ansible server supportCCSDKDan Timoneydt5972@att.com

GREEN

CCSDK-222 - Getting issue details... STATUS

Change workflow design and executionSOSeshu Kumarseshu.kumar.m@huawei.com

GREEN

SO-526 - Getting issue details... STATUS

User inteface for invoking upgrade workflowVIDOfir Sonsino os0695@intl.att.com 

GREEN

VID-201 - Getting issue details... STATUS

Testing of change design and executionIntegrationHelen ChenHelen.Chen@huawei.com

GREEN



Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?
    • The figures below show sample E2E flows that will be executed as part of NF Change. 


What other ONAP projects does this project depend on?
  • SDC
  • Portal
  • Service Orchestrator
  • Controllers
  • A&AI
  • Policy
  • DCAE
  • Optimization Framework(SNIRO)



  • How does this align with external standards/specifications?
    • It is not based on any external standards/specs
  • Are there dependencies with other open source projects?
    • There are no dependencies with other open source projects.

Resources:


Other Information:

  • link to seed code (if applicable)
    • In order to better align with target ONAP architecture all Change Management activities will be designed and executed through the appropriate components (SDC will be used to design and store workflows, SO will be used to execute them).
  • Vendor Neutral
    • No code will be delivered at least for Release 1

Use the above information to create a key project facts section on your project page

Key Project Facts

Project Name:

  • JIRA project name:Network Function Change Management
  • JIRA project prefix:NFCM

Repo name:NFCM
Lifecycle State: Incubation
Primary Contact:TBD

Project Lead:TBD
mailing list tag: NFCM 
Committers:

Emmanouil Mavrogiorgis ( emaurog@research.att.com )

Giritharan Rana ( giri@research.att.com )

*Link to TSC approval:


  • No labels

5 Comments

  1. How would configuration be handled? I guess it would come from SO directly to the VNFs? Would SO also take care of upgrading the configuration in case new parameters are added in the new version of the VNF?

  2. Configuration would be handled by the controller - APPC/VFC/SDNC. SO orchestrates the flow end to end. For example, applying a configuration change would consist of pre-checks, potentially suppressing alarms (depending on the type of change), configuration change, post-checks, impact analysis. Health checks and impact analysis can be done by DCAE. Suppressing alarms potentially done by A&AI.

  3. It looks like SW upgrade is being done by creating a new VNF with the new SW, moving traffic to the new VNF and then deleting the old VNF.  Before traffic is moved to the new VNF, a snapshot of the config data from the old VNF must be taken, then the data must be migrated to the new schema (if there is one) and the configuration must be put onto the new VNF.  Who is responsible for migration of the configuration data to the new schema?  Is that also the controller?  How would the controller know what to do?  

  4. Linda Horn Shouldn't APP-C and VF-C be responsible for migration of configuration? Shouldn't "upgrade" be considered in life-cycle of VNF and should't it be placed into TOSCA descriptors like create, remove operations? I think that handling of configuration is one point (very important one) but in general change management scenario, like shown above, looks fine but only in case of stateless VNFs like vFW. Let's consider not only configuration but also state of sessions and control dialogs - if we want to take care about them. If we don't care, upgrade can affect quality of end-user services handled by state-full VNFs being "changed". If we want to solve this problem, after locking of old VNF, or orchestrator should wait till service session will end (how long?) or we should migrate/switch also whole sessions with their state (not only traffic but also control plane). But how to do it without proper design of VNF or without adequate mechanisms in APP-C and VF-C that would support that process?

  5. Great question, Linda - Controller should handle the configuration snapshot from the old instance and then push to the new instance. This also applies if we are doing a delete-first and then build new, or an OpenStack update.

    Lukasz brings up an interesting question about traffic/state management along with config management around the software upgrades. We have also been looking at those two problems and we are working on devising a flexible solution to control when/how to complete traffic migration from old to new. This capability (traffic migration) could be driven by the controller and configured/controlled using policy.