13:01:42 <bh526r> #startmeeting Weekly Technical Discussion
13:01:42 <collabot> Meeting started Thu Oct 26 13:01:42 2017 UTC.  The chair is bh526r. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:42 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:01:42 <collabot> The meeting name has been set to 'weekly_technical_discussion'
13:01:51 <bh526r> #topic Roll Call
13:01:56 <bh526r> #info Bin Hu
13:02:11 <yujunz> #info Yujun Zhang
13:02:28 <s3wong> #info Stephen Wong
13:07:03 <bh526r> #topic New Project Proposal - Clover
13:07:20 <bh526r> #link https://wiki.opnfv.org/display/PROJ/Clover
13:07:37 <bh526r> #info Wenjing summarized what has been updated since discussion last week
13:18:36 <bh526r> #info Wenjing clarified that the internal service-to-service communication is the the communication between components within a service. If it maps to k8s terminology, it is pod-pod communication within a k8s service.
13:35:20 <bh526r> #info Dave asked if it is solely infrastructure focused or it is also VNF vendor focused?
13:36:15 <bh526r> #info Wenjing clarified that it also should be VNF vendor focused.
13:36:58 <bh526r> #info Dave also asked what will happen in OPNFV? Will we develop the requirement for CNCF to address it? or will we also develop code?
13:38:11 <bh526r> #info Wenjing clarified that we need to identify gaps, and do integration and testing. Once gaps are identified, most of work are expected in upstream, but some work may need in OPNFV too, such as prototyping.
13:38:54 <bh526r> #info Prakash indicated that the scope is too wide, such as control plane, data plane, etc. It may be decomposed into several projects
13:39:36 <bh526r> #info Wenjing said that we may not solve all problems at once in OPNFV, most of them will be worked on in upstream. So it is not starting from scratch.
13:41:50 <bh526r> #info Dave added that the scpe is good, but would like to see focus on cloud native VNF, and best practice of developing cloud native VNFs
13:44:53 <bh526r> #info Wenjing will further elaborate the main and focused tasks/deliverables.
13:51:51 <xuanjia> i am sorry i am offline....
13:57:30 <xuanjia> I think the scope of this project is wide. would like to foucs on cloud native VNF. for example, let SampleVNF use this technology as a classical example. :)
13:57:50 <bh526r> #info Dave further asked it is more network focused, is there a plan to address storage?
13:58:57 <s3wong> xuanjia: utilizing CNCF projects such as Envoy, OpenTracing, gRPC does mostly affect applications, in our case VNF --- so the focus will inevitably be on cloud native VNF (as Wenjing put on slide #1)
14:01:07 <bh526r> #info Wenjing replied that we would focus on too
14:02:00 <xuanjia> s3wong, thank. that will be good. Sounds the network and storage of container may conflict with container4nfv.
14:02:31 <s3wong> xuanjia: for networking --- the CNI plugin to use is out of scope for Clover
14:03:14 <xuanjia> so what's meaning of "focus on network and storage" ？
14:03:43 <s3wong> xuanjia: Clover's focus is on tools and integration to make VNF cloud native
14:04:43 <s3wong> xuanjia: I think the idea is to derive best practice for building cloud native VNF, we should think about what is best practice also for networking and storage from application perspective
14:05:12 <s3wong> xuanjia: but using said Calico for networking or OpenSDS for storage, that is out of scope for Clover
14:05:29 <xuanjia> best practice? How do you define "best" ?
14:05:57 <bh526r> #info General consensus is that this proposal will solve the real issue of cloud native area, and the intention is to bring it to TSC for review on Tuesday Oct 31.
14:06:21 <s3wong> xuanjia: community consensus (hopefully) on how to approach cloud native VNF --- the documentation that Dave and Bryan talked about
14:06:47 <bh526r> #info Meeting adjourned
14:06:51 <bh526r> #endmeeting