Topic Leader(s)

Topic Overview

25m, Fernando Oliveira Byung-Woo Jun, 25m Lukasz Rajewski  Seshu Kumar Mudiganti, Konrad Bańka ; 10m Q&A

This session will present the features developed in Honolulu and will share the requirement candidates for the Istanbul release, followed by a proposal of "Simplified CNF modeling".

Slides & Recording

ONAP-CNF-Taskforce-Part-1.mp4

ONAP-CNF-Taskforce-Part-2.mp4

Presentation Slide Decks

CNF Model & Package Proposal - Part 1

CNF Orchestration (CNFO) Roadmap - Part 1

CNF Model & Package Data Model - Part 2


Agenda (TBC)

  • What we did for Honolulu
    • CNFO
      • Native CNF (re)configuration supported in CDS
      • Access to k8splugin Day2 APIs in CDS
      • Query API in k8splugin
      • Healthcheck API in k8splugin aka "helm test"
      • vFW CNF use case with Day 2 and pod-deployment health check examples
    • ETSI CNF
  • What would be our plan for Istanbul
    • CNFO
      • Helm package validation in SDC
      • Helm3, helm hooks in k8splugin
      • CNF status verification as a part of the CNF deployment process
      • CNF health check workflow in SO
      • Runtime k8s information in AAI
    • ETSI CNF
  • <Simplified CNF modeling or ETSI CNF data modeling>
  • <Direct CNF orchestration thru MultiCloud and/or helm package distribution thru CNF-Adapter>

Minutes

  • This session will have two parts

Part 1

  • Presentation by Byung-Woo Jun and Thinh Nguyenphu on CNF packaging (high level, details will be covered in part 2) - refer to slides
  • Presentation by Lukasz Rajewski and  Seshu Kumar Mudiganti  on CNF orchestration - refer to slides
  • Contributors are welcome to join the effort
  • Interested parties are welcome to join the weekly CNF Taskforce meetings on Thursdays, 1  hour before the ONAP TSC meeting. Link to CNF Taskforce meeting - https://lists.onap.org/g/onap-meetings/viewevent?repeatid=31872&eventid=1123100&calstart=2021-06-03
  • Q: Will DCAE and Prometheus work side by side? Not exactly side-by-side, but rather Prometheus integrated into VES.
  • Q: How is day0/1/2 configuration modeled? A: CDS is used for configuration modeling. Instantiation parameters are in CBA. Q: Is configuration updated in A&AI? A: No. Only the resource status.After the details of ASD are figured out, there may be an impact on the information stored in A&AI. Modeling proposal under discussion -  ONAPMODEL-37 - Getting issue details... STATUS
  • Seshu Kumar Mudiganti - The current use of A&AI is an interim solution. Once there is agreement on the CNF modeling, the CNF orchestration will use it.

Part 2

  • Presentation by Byung-Woo Jun, Thinh Nguyenphu  and Fernando Oliveira - CNF Data model and packaging in-depth - refer to slides
  • Q: Will an example ASD be provided? A: Yes. May be on wiki only, without the actual network function code.
  • CNF Descriptor WIP can be tracked here: https://wiki.onap.org/pages/viewpage.action?pageId=103418711
  • Q:Why is the term "VNFD" is used? It implies a VNF, not a CNF. A: The "V" is not limited to virtual machines. Just denotes some virtualization/containerization technology. ETSI does not have a notion of "CNFD", only "VNFD"
  • ETSI Draft: https://docbox.etsi.org/isg/nfv/open/drafts/SOL001ed421_TOSCA-based_NFV_descriptors_spec/NFV-SOL001ed421v404.zip
  • Comment  - The need to keep the VNFD and Helm charts in sync is error prone. If there is a change made in the Helm (e.g. increase replica set) which is not reflected in the VNFD, the deployment may fail. There needs to be an automated mechanism to automatically update the VNFD based on changes in the Helm chart.
  • Comment - There needs to be a clear set of requirements for CNF packaging so vendors can use it for their CNFs.

Action Items

  •