Hi Dave,
There are two reasons I choose Mode III. 1) The biggest reason is there
will be no big changes for MANO and the community can accept it easily. 2)
Mode III contains the functionality of Mode II. We can still use COE API in
mode III.
Well, if the community accept to use Mode II, it's okay for me. Or we can
do both of Mode II and Mode III.
And let's talk about Mode II. There're two ways to use COE.
If I understand correctly, one is like what you said, COE acts as VNFM.
This VNFM is a generic VNFM. For example, Kubernetes is a generic VNFM , but
it only supports containers. What if we want to use virtual machine?
The other one is COE only acts as VIM. VNFD/NSD need to define how
containers and VMs are connecting and where containers are running. etc..
TOSCA need to add some features to support container. If I am wrong, please
correct me .
The flow may like this :
VNFD-->TOSCA------- if container ?-->COE
|
|----------if virtual machine ?---->Openstack Heat
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: Dave Neary [mailto:[email protected]]
>Sent: Thursday, December 08, 2016 4:37 AM
>To: jiaxuan <[email protected]>; [email protected];
>[email protected]; [email protected]
>Cc: [email protected]
>Subject: Re: Discussion for OpenRetriever
>
>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
