Hello Xuan Jia, My thinking on this is that when you are running a containerized VNF, you will interact primarily with the COE - the infrastructure (and thus, whether it's AWS, Azure, OpenStack, or MyLittleCloud APIs) should be abstracted away and is not part of the application definition - the VNFD/NSD will define QOS criteria, networking requirements, etc, and the COE should work with the VIM to ensure that the infrastructure is provisioned in a way which can meet those constraints.
If that's the case, then I think it makes more sense to target the COE interfaces directly, rather than attempt to leverage OpenStack APIs for provisioning of container workloads. In other words, I think mode ii makes more sense than mode iii. Can you perhaps explain the investment which you have in Magnum and Zun which has led you to the conclusion that mode iii is preferable, please? Thanks, Dave. On 12/02/2016 07:17 AM, jiaxuan wrote: > Hi All > Thanks for the discussion for the new project proposal OpenRetriever. I > answer these questions we have discussed in the last meeting. If I have > something misunderstood, please let me know. > > 1. If there is a baremetal deployment, in case of COE, regarding networking > part, do you intend to use kubernetes or native COE APIs. > To Prem: If we discuss it without openstack, I intend to use Kubernetes as > I am familiar with it. But Openstack has been deployed widely in CT, I have > to think about how container integrated with openstack . So we can choose > mode ii or mode iii . The reason why I want to choose mode iii is that for > mode ii, the upper layer has to use COE api to manage container, it has to > develop new plugin to suit COE api. If using Zun to translate COE api to > Openstack API, the upper layer will not change much. 'legacy', we need to > keep the previous software can work , but in mode iii, it still keeps the > Native COE APIs. > > 2. Do I meet the performance issue? > To Prem: Currently, we don't meet the performance issue. We only tested vIMS > . Well, for other VNFs, it may need DPDK technology or others to > accelerate the network speed. This proposal we have considered to integrate > DPDK , SR-IOV and others . As far as I know Intel is working on it. > > 3. If to use kubernetes on top of OpenStack i.e. kubernetes as VNFM and OS > as VIM (Model 2) , why to prefer Model 3 than Model 2 > To Dave: I think kubernetes is a kind of COE and controls the resources > like CPU. Kubernetes could be a VIM. But if to make Kubernetes as VNFM, it > will be mode 1. If I misunderstand, please correct me . > > 4. if there is an explicit goal of interoperability of VNFs instantiated by > VMs and Containers > To Steve: Well, I don't think so. Kuryr project ( > https://github.com/openstack/kuryr ) can provide network for container. > Containers can connect to VMs and VMs can connect to containers. > > 5. why does it mean to change COE API to native API? > To Bryan: I am sorry I didn't understand the question yesterday. I meant > change COE api to Openstack API. Then the container can be managed by > Openstack. For the upper layer, we will not change many things. If the > total platform is containerized, the upper layer has a lot of things to > modify. We can make it step by step. Collaborate with community to add new > feature in TOSCA and standardized VIM Api. If COE API can be the stand API > of VIM, this proposal will be simple. > > 6.suggested to create software within existing scenarios instead of creating > additional OPNFV scenarios, those container components can be added to > existing scenarios. > To Chris ,Bryan, Uli: > I am sorry, what do you mean 'the existing scenarios' ? Could you give me > some examples? Thanks. > OpenRetriever focus on the container integrated with openstack and how > containerized VNF runs in the platform. It not only needs to install > additional components, but also integrated DPDK and other container > technology to let the VNF run in the container. > > Good talk with you > > BR > > Xuan Jia > Project Manager > Big Data & IT Technology Research Center China Mobile Research Institute > 32 Xuanwumen West Street, Xicheng Distirct, Beijing 100032, China > Mobile: (+86) 3811000575 > E-mail: [email protected] > > > > -- Dave Neary - NFV/SDN Community Strategy Open Source and Standards, Red Hat - http://community.redhat.com Ph: +1-978-399-2182 / Cell: +1-978-799-3338 _______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
