...
- 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
- Tried both types of packages - ETSI and ONAP
- Experience is with the Frankfurt release (Heat template wrapper)
- ONAP VNFD - Under TOSCA There is a namespace. If a vendor uses its own namespace it does not work out of the box. Expect to have a way to change the namespace supported by ONAP. There was a requirement for SDC to support changing the namespace. Workaround - Change the CNF package provided by the vendor to match the ONAP namespace.
- While designing a service using SDC, ran into an issue with the interfaces as defined by the vendors - use different types than the ones supported by ONAP.
- Christophe Closset - There were changes made in Honolulu - https://wiki.onap.org/download/attachments/100895762/SDCMultiModelSupport.pptx?version=1&modificationDate=1618834987000&api=v2&download=true
- Kamel Idir - Is there support for SOL007 design? Christophe Closset - It might be included in the recent changes (Honolulu). There is a way to indicate whether you are using ONAP or ETSI package.In the future it might be possible to translate between the two formats.
- SDC has a limitation on size of images in the Helm charts. SDC has a 8MB limitation. Kamel Idir indicates it is not sufficient for the CNFs he on-boarded. Workaround - Onboard images to Docker image registry and reference them. Some vendors provide embedded images which will require modification. Christophe Closset - The solution might not be having SDC handle the images. It is not designed to serve as image storage. Kamel Idir- Manipulating the package provided by a vendor to extract the images might jeopardize package integrity. Zu Qiang (Ericsson) - Extracting the images during on-boarding may not impact the integrity. Integrity validation happens before the extraction of the images. Flow is (1) Validate - signature validation (2) Extract (3) Distribute (no signature validation at this stage).
- Kamel Idir - volunteered to provide feedback based on his experience
April 29nd, 2021 at 1pm UTC
- Seshu Kumar Mudiganti - Updates or requests from the XGVela project
- Byung-Woo Jun - Update on the Magma interface analysis.
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
- Kamel Idir - Will repeat onboarding with Honolulu (once he has the lab resources) and will report back
- (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
...