Skip to content

Enable NS level actions for Helm-based Execution Environments

Proposers

  • Sepand Seradj (Resaa LLC)

Description

This proposal aims to introduce the capability to define and execute actions (config primitives) at the Network Service (NS) level when the constituent Virtual Network Functions (VNFs) within that NS are managed using Helm-based Execution Environments (EEs).

Currently, OSM supports defining configuration and actions at the VNF level for Helm EEs. OSM also supports NS-level configuration and primitives, but the primary method highlighted for NS Configuration is via Juju charms, and NS-level actions leveraging Helm EEs are currently not fully supported. There is a gap in providing comprehensive NS-level action capabilities that can leverage a Helm-based EE deployed at the NS level to orchestrate or control actions on VNFs that are themselves deployed using Helm EEs.

The objective is to enable users to define an NS-level Execution Environment using a Helm chart within the Network Service Descriptor (NSD). This NS-level Helm EE would host primitives capable of interacting with the Helm EEs managing the individual VNFs within the NS instance.

The underlying descriptor structure in OSM's Information Model (IM) already includes elements that support the declaration of this capability. The etsi-nfv-nsd module, augmented by ns-configuration, contains the /nsd:nsd/nsd:nsd/ns-configuration:ns-configuration container. Within this container, the config-method choice includes an execution-environment-list option. The execution-environment-list allows specifying an execution-environment-model, which explicitly supports a helm-chart type for an NS. Furthermore, the config-primitive list within /nsd:nsd/nsd:nsd/ns-configuration:ns-configuration allows defining named primitives associated with an execution-environment-ref (which can point to the NS EE defined in the execution-environment-list) and an execution-environment-primitive (the specific action name within the NS EE chart). Parameters can also be defined for these primitives. This structure indicates that the descriptor model supports the declaration of NS Helm EEs and their primitives. The primary work required is implementing the Lifecycle Management (LCM) logic to execute these defined primitives and enable the necessary interaction and coordination between the NS Helm EE and the constituent VNF Helm EEs.

This feature is motivated by several key use cases identified in our conversation history:

  • Orchestration Between Multiple VNFs: An NS-level action can coordinate complex operations across several VNFs using their Helm EEs. For example, a "Provision Service" action at the NS level could trigger a sequence of provisioning primitives on individual VNFs, ensuring dependencies are met (e.g., VNF A configures networking, then VNF B configures application services leveraging VNF A's setup). This highlights the need for the NS Helm EE to interact with constituent VNF Helm EEs.
  • Synchronization of Multiple VNF Instances: When multiple instances of the same VNF are deployed for high availability or disaster recovery within an NS, an NS-level action (like "Apply Configuration Update") can ensure that a day-2 operation is applied consistently and perhaps in a coordinated manner across all relevant VNF instances.
  • Simplified High-Level Actions: Common actions applicable to multiple VNFs within an NS, such as a "Health Check", can be triggered via a single NS-level action. This provides a simplified, high-level view of the NS health by consolidating the status from individual VNF health checks without needing to trigger actions on each VNF individually.

Implementing this feature will primarily impact the Information Model (IM) to potentially refine or extend the existing YANG models for clarity, the Lifecycle Management (LCM) module to handle the execution logic, and the osmclient to expose the new functionality to users. The core technical challenge lies in designing "How the helm-based EE for the NS will be able to run primitives from other helm-based EE for the VNFs". Work is anticipated in LCM files such as osm_lcm/ns.py and osm_lcm/lcm_helm_conn.py.

Demo or definition of done

The successful implementation of this feature will be verified through end-to-end testing. The definition of done includes:

  • Updated or new NS descriptor schema elements within the Information Model (IM) to clearly support defining NS-level Helm EEs and their primitives.
  • Implementation in the Lifecycle Management (LCM) module to process these descriptor elements, deploy the NS Helm EE (with consideration to its deployment namespace), and execute NS-level primitives, including enabling the NS Helm EE to trigger and coordinate primitives on constituent VNF Helm EEs.
  • Updates to the osmclient to allow users to upload NSDs with NS Helm EE definitions, instantiate NSs using these NSDs, and trigger the defined NS-level actions.
  • The creation of a new or updated robot test suite to demonstrate and validate the core functionality, including onboarding an NSD with NS Helm EE, instantiating the NS, successfully executing an NS-level action, and observing the expected behavior on the constituent VNFs. This aligns with the approach for testing new features like "NS config templates".