Page History

For Guilin release there are introduced key changes that deployment of CNFs with ONAP more operational and they enable Day-0/1 CNF operations. The changes include:

• Native distribution of Helm package from SDC
• Native support for Helm package enrichment in Controller Design Studio.
• Native orchestration of Helm package in the SO
• Exposure of APIs for monitoring of resources deployed on K8s cluster

The introduced changes bring the following benefits:

• Native distribution of Helm package in SDC enabled native orchestration of CNF in SO and allows the addition of Helm validation or Helm properties recognition in the future
• Native support for Helm package enrichment in CDS allows the flexible generation of Helm override parameters and enables easy modification of on-boarded Helm package for each service instance. It is very important for the deployment of complex 5G Core CNFs that require heavy customization for each deployed service instance.
• Native orchestration of Helm package in the SO enables further synchronization of ONAP inventory with information from k8s cluster or easier execution of Day-2 operations on CNFs
• Exposure of APIs for monitoring of resources deployed on K8s cluster enables verification of the status of k8s resources deployed in k8s cluster. Currently, such API can be easily integrated with CNF blueprint created for Controller Design Studio.

The Control Loop sub committee led the functional requirement to add a new Filter Guard Policy Type. In addition, the subcommittee ensured that the Native Policy Type work developed in Frankfurt was fully tested through the CLAMP interface.

The sub committee continues to support the DCAE Project Self-Serve control loop enhancements Proof-of-Concept. The PoC made improvements to MOD (NiFi) and configuration for dynamic topic support.

A new Proof-of-Concept was started by the subcommittee to define TOSCA-Based Control Loops. This work was demonstrated at the fall LFN Technical Conference.

The new Filter Guard Policy Type is another guard policy available for ONAP users to use in addition to the others that have been available since Dublin. This allows filters to build more flexible constraints to both whitelist and/or blacklist vnf types, specific vnf id's, services, etc.

In defining a TOSCA specification for Control loops, users can now encapsulate all the details of a control loop within one specification. These specifications are re-usable. CLAMP will eventually be able to be fed a TOSCA specification, and with minimal effort be able to configure and deploy a control loop into the runtime environment.

The modeling subcommittee updates the ONAP VNFD model to align with ETSI NFV IFA011 v2.7.1, supporting key features like virtual ip, VNF exposed interface, etc.

The subcommittee also adds a new model for location information. Taking consideration of multiple existing standards, including ETSI NFV SOL001, RFC4776 and RFC6225, the new model enables an entity to provide its geographical location information.

Update of the VNFD model to the latest ETSI NFV spec allows ONAP to incooperate new features defined in standards.

The new locations model enables entity such as PNF to provide its geographical information, allowing further scheduling and optimization procedures.

Progress with packages package and Java, Python versions upgrades,

Progress with decrease of packages pods running as root

Migrations Migration towards https and usage default use of https as default

Open Lab 

Network slicing would be able to deploy in 5G by using ONAP, with internal nd external NSSMFs, CSMF and NSMF;

any combination of PNF, VNF, CNF would be applicable for any use case

deployment will be enabled by standardized ETSI SOL functionalities

• Native support for Helm package enrichment by CDS
• CDS Designer Enhancements 
  • Package List/Search
  • Package Import 
  • Package Creation
    • Meta Data
    • Template & Mapping with Velocity, JINJA support
    • Script
    • File Import
      
      • Save & Deploy 
      • Save 
    • Manual Enrichment

• Native support for Helm package enrichment in CDS allows the flexible generation of Helm override parameters and enables easy modification of on-boarded Helm package for each service instance. It is very important for the deployment of complex 5G Core CNFs that require heavy customization for each deployed service instance.
• Delivered MVP (minimal viable product) Functionality to support Package Designer capabilities for design & creation of the CBA package. 

• Exposure of APIs for monitoring of resources deployed on K8s cluster
• Improvements in configuration API for modification of existing resources
• Improvements in profiling (helm enrichment) mechanisms

• Exposure of APIs for monitoring of resources deployed on K8s cluster enables verification of the status of k8s resources deployed in k8s cluster. Currently, such API can be easily integrated with CNF blueprint created for Controller Design Studio.
• Change in Configuration API allows modification of existing resources created before by helm package.  The mechanisms can be used for standard Day2 operation, like modification of configmaps, deployment, or for upgrading purposes.
• Modification of the profiling mechanism enables the use of one definition and profile for the creation of many instances of CNF.  Before, for each instance, a separate profile was required.