Xuan Jia, What we meant re current scenarios, are what we build and test in CI/CD, with various combinations of components and feature-specific code that adds to the basic scenario components. We would need to see what components you intend to add beyond Kuryr, to know if a new scenario was needed. But the goal is not to add new scenarios due to the resource/process overhead.
And just FYI, it would be good for us to align on terms here. Note that re " let the VNF run in the container", a VNF won't run "in a container", unless the VNF has a single VNF Component (VNFC) and this needs only one VDU (Virtual Deployment Unit). Containers as with VMs are one of the options for VDU deployment. This is related to my comment on the call that the VIM should support VNF deployment in a mix of VDU types, for VNFs that have multiple VNFCs. Multi-VNFC VNFs will likely the the most common case, so we need to think and refer to VNFs running in "a set of containers and/or VMs" or more generically "a set of virtualization hosts". On Dec 2, 2016, at 4:17 AM, jiaxuan <[email protected]> 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] _______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
