Thanks Bryan. That's a good point. Yes, we will let VNF run on a set of
containers and/or VMs. For this project, I think there are two projects
(Kuryr and Magnum) needed to be add in . Zun project just starts up , maybe
we can start this proposal from Mode II.
So There are three things to accomplish in this proposal :
1. Add Kuryr and Magnum into installers.
2. Container for NFV. Sounds like KVM4NFV, but the main function is to
increase the performance of container in OPNFV.
3. Give a way to manage container and virtual machine in one platform.
Thanks
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]
>-----Original Message-----
>From: SULLIVAN, BRYAN L [mailto:[email protected]]
>Sent: Monday, December 05, 2016 2:24 AM
>To: jiaxuan <[email protected]>
>Cc: Dave Neary <[email protected]>; [email protected];
>[email protected]; [email protected]
>Subject: Re: Discussion for OpenRetriever
>
>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
