...
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?
- 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?
...
- You can create a JIRA ticket - https://jira.onap.org/
- You can post any question on the #integration-team channel in the onapproject.slack.com Slack instance
- You can also join the CNF Task Force, every Thursday prior the ONAP TSC Call (1pm UTC) calendar link
- You can also write to the onap cnf mailing list - onap-cnf-taskforce@lists.onap.org
Q: Are there "CNF requirements" available in ONAP, similar to the "VNF Requirements"?
- A: Helm 3 is supported in Honolulu (maintenance release). Helm hooks are not fully supported.
- CNF Descriptor Proposals: https://wiki.onap.org/x/VwsqBg
- Architecture Review: [ONAPARC-709] (Istanbul-R9) - Func - CNF Orchestration – Istanbul Enhancements
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 server ONAP Jira serverId 425b2b0a-557c-3c0c-b515-579789cceedb key REQ-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?
- Control loop, DCAE, A&AI, ASD implementation, Prometheus integration with VES, and more. Refer to 2021-06-09 - ONAP TSC Taskforce: Cloud Native (Roadmap)
Q: What do we need to ask to CNF Vendors to be onboarded on the ONAP Platform?
- Vendors are welcome to test their CNFs, so we can have the solution validated with a larger set of Network Functions
A:
Questions from the audience
Action Items
- Security container logging requirement 2021-02-22_LoggingRequirementEvents_v8 (1).pdf
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.