Description:

In ONAPARC-244, https://jira.onap.org/browse/ONAPARC-244  there assumptions for the orchestration of container based VNFs was presented.  This lead to a discussion on the assumptions, this is to clarify the assumptions.

 

2018-10-30 Arc Dublin F2F:

Srini presented the slides:

Aim for Dublin:

• Support containerized workloads
• VFW case
• EdgeX use case -

There is a call out for the VNF assumptions for K8, K8 and VMs etc that are being addressed.

there are archiectual work to be done regarding how it works accrsso the different functions in ONAP

There is a call to ensure that DevOps is considered.

There is need to clarify how the cloud specific artifacts are passed around, there is the suggestion that it should stay in the Multif-vim.

Stretch goadl: add change management as well as SW upgrade

There were qeustions about how to achieve the isolation between VNFs. 

There was comments that we have questions around alignment with modellign and alignment.

Think about how multivim interfacts with the cloud layer.

NEed to come back in two weeks.

 

 

------

Meeting notes 2018-08-16

 Presentation: https://wiki.onap.org/download/attachments/8225716/K8S_R4_E2EIntegration.pptx?api=v2 

• Assumes VIM technology specific VNFDs (HOT, HELM, ...).  TOSCA considerations will be taken onboard at the conclusion of the TOSCA taskforce.  Timing of that will then be considered.
• These are loaded in seperately to SDC.
• Propose that SO and SDC are cloud technology independant, and multi-vim takes care of VIM technology dependance.
• There was questions regarding the SDNC impact due to IP address allocation (Assign) capabilities.  This needs to be looked at.
• Assumed that there is no impact on the NSD.  There is the assumption that the NSD is not onboarded to SDC.
• There was a question regarding about how SO understands the cloud technology in order to know what to send to multi-cloud, by sending the cloud-region information to multi-vim. 
• It was recomended to minimise dependancies on other activities and projects for the dublin release.
• When changing SO, the idea is to change SO so that its independant of the VIM technologies.
• Suggestion to have example "flows" for the different steps, where the service as a couple of K8 based VNFs.
• Suggestion to allow the VNF provider to have the flexibility of the VNFD. ie. allowing the VNF to have different VNF packages for different VIM technologies
• It was noted that there are two different approaches, this one; and the TOSCA technology independant approach.
• Highlight the parts that are sensistive to the conclusions of the TOSCA taskforce.
• Consider also the VNFM plug-in.
• Are there any inputs to the VNF LCM.
  • Request to highlight the VNF LCM capabilities are impacted.  It was commented that quite some of that is outsourced to K8.
• Note: The implicit assumption that the idea is to use K8
• Way forward:
  • List VNF LCM capabilities and where we think they would be executed with openstack (today) and K8.
  • Same for the service.
• Way Forward:
  • Document more details, assumptions, etc as described above
  • Consider VNF SDK and SDC SO impacts