...
- Lukasz Rajewski and Seshu Kumar Mudiganti will share the plans for Istanbul. May be in WIP state.
- no updates yet.Jira server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key REQ-627 - No architectural changes expected.
- Marian Darula - Are Helm charts alone sufficient for modeling CNFs, or is there a need for external modeling. Lukasz Rajewski - Multi cluster is still a challenge.
- Byung-Woo Jun & Marian Darula - There is a need for an additional descriptor. The ETSI approach of a TOSCA descriptor on top of Helm could be a good approach. Lukasz Rajewski - The multi-cluster network connectivity is an example of a modeling aspect that needs to be handled outside the Helm charts. The Nokia proposal may hold the solution for this issue.
From user-67d6f : I have created the place holder for supporting the CNF badging from ONAP perspective here https://wiki.onap.org/display/DW/Anuket+Assured+-+ONAP+CNF+Compliance+Badge
In order to plan the same for next release, would like to get filled following items asap from CNF Task Force and Modelling team. Could you please help to identify the owners for the below items. Thank you1.CNF Model Element Structure
- This is related to our discussion on reaching consensus on packaging
- 2.CNF badging requirements
We would like to get a better understanding of what the requirements should look like.
3.Sample CNF (ex: vFW) already supported in ONAP
Only existing NF is the vFW, but it is not optimal as a "CNF reference". Other "Reference CNF" proposed by Samsung is not yet on-boarded to ONAP. Catherine Lefevre - the 5G-Super-Blueprint is working on on-boarding Magma (https://wiki.lfnetworking.org/display/LN/LFN+Demo%3A+5G+Super+Blueprint)
April 15th, 2021 at 2pm UTC
- Lukasz Rajewski and Seshu Kumar Mudiganti will share the plans for Istanbul. May be in WIP state.
Jira server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key REQ-627 - Seshu Kumar Mudiganti - Updates or requests from the XGVela project
April 22nd, 2021 at 2pm UTC
- Invite CNF vendors to provide feedback on the CNF onboarding based on their experience with their CNFs.
- Kamel Idir - volunteered to provide feedback based on his experience
- Catherine Lefevre will invite SDC PTL
Action Items (In Progress)
- Byung-Woo Jun / Marian Darula - Provide the Ericsson packaging proposal.
- (Modeling/Requirements): Need to determine what ETSI CNF package solution we want to move forward (Fernando Oliveira, Byung-Woo Jun vs Thinh Nguyenphu)
- (Thinh Nguyenphu): Share an alternative (Common CNF Packaging) to what was proposed by Fernando Oliveira , Byung-Woo Jun
- (Olivier): Check with CNCF if any cross-meeting with ONAP could be scheduled
- (All): Collect feedback about our current CNF onboarding capabilities from 3rd party vendors
- (All): Build an ONAP proposition value to collaborate with XGVela Community
- (Seshu): Questions for XGVela
- It would be great to highlight more clearly the purpose of XGVela as a platform to build CNFs and get feedback from 3rd party vendors, who are today already creating CNFS for carriers, to assess the value proposition
- After the CNF is created via XGVela – can we then deploy the CNF on any Cloud environment without using XGVela at run-time?
- If we need XGVela then have we performed an analysis to demonstrate the value proposition vs K8S and its ecosystem?
- Build a slide to highlight how XGVela (i.e. create CNF) is complementary to ONAP (onboard CNF/orchestrate CNF, etc.) and how it will fit to the CNCF Landscape
- (All) Try to identify where we are on the CNCF Trail Journey - Needs clarification to comment, need to dig into the details of the actual ask.
...