Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Excerpt

30m(-60m)

This session is an open forum to collect feedback, raise any question and provide suggestions from the people who are attending the DDF event to the ONAP "Cloud Native" TSC Task Force.

Slides & Recording

...

View file

...

titleYouTube

...

  • Live Interactive Session

nameONAP-CNF-AMA.mp4
height150

Agenda

To be determined by the people who will attend to this session

Minutes

FAQ

Q: What is the value-add of ONAP for CNF orchestration (CNFO)? What does it provide on top of K8S?

A: Lukasz Rajewski Konrad Bańka Byung-Woo Jun

  • hybrid config and data operations can work on both K8s and PNFs 
  • Can manage helm charts
  • Handling multi-cluster deployment on top of K8S
  • ONAP works in the service level, not just the resource level 
  • Still need to address coordination across different clusters and SW upgrades

Q: What can end users do with ONAP Honolulu? What operations are supported (service design? Deployment? Day-0 configuration? Day 1/2 configuration? LCM?), and what will be supported in Istanbul?

  • A: Lukasz Rajewski For the "native helm" path - on-boarding, Helm enrichment with CDS, meaning modifying values in Helm templates.
  • Day 2 operation config-assign/config-deploy - add/modify resources after the initial deployment, which may be used for upgrade.
  • CNF status checking is supported in Honolulu, will be enhanced in Istanbul.
  • Seshu Kumar Mudiganti SO merged the "native helm" and "ETSI" paths for a more 'Plug&Play'

Q: What is the format of CNF packaging? Is it based on Helm? Does it follow ETSI-NFV specifications?

AFernando Oliveira

  • packaging - SOL04 may need a bit of work still. Descriptors are still being discussed in ETSI about containerized models. Lots of discussion but no consensus yet.  Orchestration meetings on Mondays 8am Eastern
  • Packaging is based on the CSAR format (for both the 'helm native' and 'ETSI' Format
  • CNF Descriptor Proposal page:  https://wiki.onap.org/x/VwsqBg 
  • Magma CNF onboarding is following similar path than what we have implemented for CNF vFW

Q: Where is the documentation for CNF on-boarding and deployment? 

Q: How should end users report issues 

A:

issues 

Q: Are there "CNF requirements" available in ONAP, similar to the "VNF Requirements"?

Q: How could developers get involved? Where do you mostly need help? Are there open Jira tickets people can start working on?

A: 

  • Call for developers to implement in Jakarta new features:
    • CNF Control Loop 
    • Integration with XGVela
    • Merging Native Helm/ETSI flows
    • Entreprise use cases
    • etc
  • Istanbul CNF Orchestrator Requirements: 
    Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyREQ-627
  • Those are the short term goals. Have a great deal more in the backlog for future released. refer to 2021-06-09 - ONAP TSC Taskforce: Cloud Native (Roadmap)

Q: What it is not supported today and is part of the roadmap?

Q: What do we need to ask to CNF Vendors to be onboarded on the ONAP Platform?

A: 

Questions from the audience

Action Items

  •  

?

Q: What has changed in CNF packaging since Frankfurt?

  • A: In Frankfurt, the Helm chart was a 'second class citizen' in SDC. In Honolulu there is native support for Helm charts. SO understands Helm type now.

Q: Is there a plan to support NETCONF configuration, or will the solution be limited to CDS CBAs? Is there alignment with C&PS?

  • A: No integration with C&PS, but it may happen at a later stage. But this is a good approach and may be discussed further in the CNF Taskforce.