Before editing please read instructions here.

 Description of Use Case / Requirement:

Today new emerging infrastructures based on kubernetes are becoming very popular. ONAP components shall support CNAs/CNFs artifacts, cloud native service models and relevant distribution/management. Given the fact that K8s has its own orchestration capabilities that partially overlap with ONAP capabilities, it is expected that ONAP development focuses first on aspects not covered by K8s. The envisioned scenario is based on both CNFs and PNFs. Moreover kubernetes provide a declarative approach to the orchestration of many aspects such as resource provisioning, resource scaling and resiliency and can be enhanced with many add-ons that seamlessly provide other features such as application control, communication robustness etc (e.g service mesh by Istio).  ONAP provides a good level of flexibility in service orchestration (e.g. a la carte, Macro and E2E orchestration approaches) but the framework requires specialized skills to implement unforeseen orchestration patterns that may slow down new service design and deployment. It is therefore required that ONAP functional module adopts a declarative approach and native support for CNAs artifacts to avoid time to market bottlenecks.  

Requirements are here below described:

R1  A clear ONAP development strategy along with relevant pattern shall be established

R2   ONAP development strategy should be in line with CNTT/CNCF

R3   ONAP development shall focus on complementing K8s capabilities

          Comment: due to limited resources it is not worth duplicating functionalities because that slow down the adoption of a full automation stack

          Comment: ONAP/K8s functional split investigation should drive priorities

          Comment: ONAP functionalies already provided by k8s should be developed with lower priorities with respect to ONAP distinguished functionalities (e.g. capability to design an E2E service that include PNFs and CNFs)

          Comment: Some ONAP/k8s overlapping functionalities may applies to different use case that cannot be fulfill by both frameworks. Use cases must be identified to drive priorities to overlapping functionalities (e.g. inter-k8s clusters closed loop can be carried out by ONAP only while intra-k8s cluster closed loop can be carried out by both ONAP and k8s. Whenever possible ONAP development should give higher priority to the features that enable inter-k8s clusters closed loop)

R4   ONAP components must be designed in a way to easily support customized services

         Comment: ONAP shall support customized services at the same pace of k8s to avoid being a bottleneck). That implies the following requirements

R4.a) Generic programming skills (i.e. not ONAP related) should be enough to add custom behaviors to ONAP framework (e.g. the same way k8s provide Controller pattern to implement customized features)

R4.b) Declarative approach must be preferred whenever possible (e.g. this is particularly true for SO and Controllers)

R4.c) Adopt a seamless solution that span run-time modules to avoid manual configuration re-work when new sevices/life cycle management actions are introduces

R4.d) Changes to functional configurations shall be easily carried out (e.g. changes to A&AI schema should be simple)

R4.e) Centralized all aspects of service design within a single environment and wizard support

R5   ONAP use cases must focus on CNAs/CNFs and PNFs only

R6   ONAP components must seamlessly support CNAs/CNFs and Cloud Native infrastructures

         Comment: there are many gaps that are currently uncovered about CNAs/CNFs like an adequate AAI representation, LCM jobs

          Comment: Adapt ONAP components functional role when applied to CNAs/CNFs and K8s (e.g. Should same level of data details be stored in A&AI for a cloud native service with respect to the ones stored for VNFs and Openstack?)

R7   ONAP shall be able to orchestrate the life cycle management of end-to-end 5G slicing solution involving RAN, Transport and Core 

Owners (one of these should be the Assignee - use @ notation):

 

Link to HLD/LLD (if any):

 

Dependency Relationships with Other Projects:

 

Project (ONAP Component #1) IMPACT: TO/C

• Impact Type: TO/C (Test Only/Code)
• Company Engagement: xyz
• Resources: xyz (People)
• Support Status: S/P/N (Supported/Partially supported/Not supported)

Project (ONAP Component #2) IMPACT: TO/C

• Impact Type: TO/C (Test Only/Code)
• Company Engagement: xyz
• Resources: xyz (People)
• Support Status: S/P/N (Supported/Partially supported/Not supported)

  

Integration Leads (use @ notation):