ASD-based CNF Orchestration

Executive Summary - Application Service Descriptor (ASD) is a simplified deployment descriptor for cloud-native applications/functions. This functional requirement is for enabling a vendor provided Application Service Descriptor (ASD) compliant CNF package including an ASD CNF Descriptor to  be orchestrated by ONAP SO and its sub-components. The function will provide ASD-based CNF runtime onboarding, distribution and orchestration.

• Support ASD package runtime onboarding

• Support AS LCM RESTful protocol APIs

• Support ASD-based CNF orchestration operations, such as Create AS, Instantiate AS, Terminate AS and Delete AS (Upgrade AS as a stretch goal), providing:

  • External K8s Clusters registration

  • AS topology inventories

  • Helm charts deployment to a selected K8s cluster

Business Impact - Enables operators and service providers to use ASD-compliant CNF packages with ONAP to simplify CNF design and orchestration, by minimizing duplication, using Kubernetes management capabilities and providing clean separation between high-level orchestration and cloud-native application deployment.

Business Markets - All operators that are currently using ETSI packages and descriptors to deploy CNFs can consider ASD-based CNF package deployment and orchestration

Funding/Financial Impacts - Reduction in operations expense from using simplified CNF packaging and orchestration.  Reduction in capital expense from vendors using a simplified packaging and deployment methodology.

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. 

JIRA: REQ-1394: Provide ASD-based CNF Onboarding, Distribution & Orchestration capabilitiesDone 

External secure communication only via Ingress

Executive Summary - When ONAP is deployed using Service Mesh (default: Istio) all internal communication between pods is secured by sidecars. If components expose there services outside ONAP (e.g User interfaces, APIs,...) they have to use the Ingress Gateway provided (here Istio-Ingress). A communication via NodePorts is not supported anymore.

• Helmcharts need to:

  • provide an Ingress resource (use existing helm template - common/templates/_ingress.tpl)

  • provide an Ingress configuration (as part of the values.yaml)

  • disable any Nodeport settings in services (if not use _service.tpl)

Business Impact - Supports a cloud-native application deployment.

Business Markets - 

Funding/Financial Impacts - 

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. 

JIRA: REQ-1351: External secure communication only via IngressDone

Removal of AAF

Executive Summary - AAF is an unmaintained component used to create TLS certificates for ONAP services. When ONAP is deployed using Service Mesh (default: Istio) all internal communication between pods is secured by sidecars. Components just need to provide non-TLS interfaces.

• Removal of the AAF component means:

  • removal of AAF from the OOM helm charts

  • ONAP Component Services must offer "plain" non-TLS interfaces

  • ONAP Components must be able to uses not-TLS interfaces of other components 

• (Optional) Code cleanup

  • When AAF is not used anymore, all AAF related code can be removed

  • All chart options related to AAF can be cleaned

Business Impact - Supports a cloud-native application deployment.

Business Markets - 

Funding/Financial Impacts - 

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. 

JIRA: REQ-1349: (London-R12) - Removal of AAFDone

All component must be able to run without MSB

Executive Summary - In the default ONAP deployment case using ServiceMesh, an Ingress Gatweay is used for external access to the services. Therefor the MSB component would not be needed and must be disabled. All components must be able to run without the usage of MSB.

Business Impact - Supports a cloud-native application deployment.

Business Markets - 

Funding/Financial Impacts - 

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. 

JIRA: REQ-1350: All component must be able to run without MSB In Progress