Open Stack

On Wed, Sep 14, 2016 at 9:39 AM, Liping Mao (limao) <limao at cisco.com> wrote:

> > Though, not the best person to comment on macvlan vs ipvlan, one
> limitation of macvlan is that on physical interfaces, maximum possible
> number of random mac generations may not cope-up with large number of
> containers on same vm.
>
> Thanks, yes, it is a limitation, Vikas.
> This happened if you use vlan as tenant network. If tenant network use
> overlay mode, maybe it will be a little bit better for the mac problem.
> The reason why I mention macvlan can be one of choice is because ipvlan
> need a very new kernel , it maybe a little bit hard to use in prod
> env(AFAIK).
>

You have a valid point regarding ipvlan support in newer kernel versions
but IIUC overlay mode might not help if nic has a limit on max number of
macs that it supports in hardware.



>
> Regards,
> Liping Mao
>
> From: Vikas Choudhary <choudharyvikas16 at gmail.com>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: 2016年9月14日 星期三 上午11:50
>
> To: OpenStack List <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal
>
>
>
> On Wed, Sep 14, 2016 at 7:10 AM, Liping Mao (limao) <limao at cisco.com>
> wrote:
>
>> Hi Ivan and Gary,
>>
>> maybe we can use macvlan as ipvlan need very new kernel.
>> allow-address-pairs can aslo allow different mac in vm.
>> Do we consider macvlan here? Thanks.
>>
>
> Though, not the best person to comment on macvlan vs ipvlan, one
> limitation of macvlan is that on physical interfaces, maximum possible
> number of random mac generations may not cope-up with large number of
> containers on same vm.
>
>
>>
>> Regards,
>> Liping Mao
>>
>> From: Liping Mao <limao at cisco.com>
>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>> Date: 2016年9月13日 星期二 下午9:09
>> To: OpenStack List <openstack-dev at lists.openstack.org>
>>
>> Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal
>>
>> Hi Gary，
>>
>> I mean maybe that can be one choice in my mind.
>>
>> Security Group is for each neutron port，in this case，all the docker on
>> one vm will share one neutron port（if I understand correct），then they will
>> share the security group on that port，it is not per container per security
>> group，not sure how to use security group in this case？
>>
>> Regards，
>> Liping Mao
>>
>> 在 2016年9月13日，20:31，Loughnane, Gary <gary.loughnane at intel.com> 写道：
>>
>> Hi Liping,
>>
>>
>>
>> Thank you for the feedback!
>>
>>
>>
>> Do you mean to have disabled security groups as an optional configuration
>> for Kuryr?
>>
>> Do you have any opinion on the consequences/acceptability of disabling SG?
>>
>>
>>
>> Regards,
>>
>> Gary
>>
>>
>>
>> *From:* Liping Mao (limao) [mailto:limao at cisco.com <limao at cisco.com>]
>> *Sent:* Tuesday, September 13, 2016 12:56 PM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev at lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [Kuryr] IPVLAN data path proposal
>>
>>
>>
>> Hi Ivan，
>>
>>
>>
>> It sounds cool！
>>
>>
>>
>> for security group and allowed address pair，
>>
>> Maybe we can disable port-security，because all the docker in one vm will
>> share one security group on the vm port. I'm not sure how to use sg for
>> each docker，maybe just disable port-security can be one of the choice.
>> then do not need allowed address pairs in this case.
>>
>>
>>
>>
>>
>> Regards，
>>
>> Lipimg Mao
>>
>>
>> 在 2016年9月12日，19:31，Coughlan, Ivan <ivan.coughlan at intel.com> 写道：
>>
>>
>>
>> *Overview*
>>
>> Kuryr proposes to address the issues of double encapsulation and exposure
>> of containers as neutron entities when containers are running within VMs.
>>
>> As an alternative to the vlan-aware-vms and use of ovs within the VM, we
>> propose to:
>>
>> -          Use allowed-address-pairs configuration for the VM neutron
>> port
>>
>> -          Use IPVLAN for wiring the Containers within VM
>>
>>
>>
>> In this way:
>>
>> -          Achieve efficient data path to container within VM
>>
>> -          Better leverage OpenStack EPA(Enhanced Platform Awareness)
>> features to accelerate the data path (more details below)
>>
>> -          Mitigate the risk of vlan-aware-vms not making neutron in time
>>
>> -          Provide a solution that works on existing and previous
>> openstack releases
>>
>>
>>
>> This work should be done in a way permitting the user to optionally
>> select this feature.
>>
>>
>>
>>
>> *Required Changes*
>>
>> The four main changes we have identified in the current kuryr codebase
>> are as follows:
>>
>> ·         Introduce an option of enabling “IPVLAN in VM” use case. This
>> can be achieved by using a config file option or possibly passing a command
>> line argument. The IPVLAN master interface must also be identified.
>>
>> ·         If using “IPVLAN in VM” use case, Kuryr should no longer
>> create a new port in Neutron or the associated VEth pairs. Instead, Kuryr
>> will create a new IPVLAN slave interface on top of the VM’s master
>> interface and pass this slave interface to the Container netns.
>>
>> ·         If using “IPVLAN in VM” use case, the VM’s port ID needs to be
>> identified so we can associate the additional IPVLAN addresses with the
>> port. This can be achieved by querying Neutron’s show-port function and
>> passing the VMs IP address.
>>
>> ·         If using “IPVLAN in VM” use case, Kuryr should associate the
>> additional IPVLAN addresses with the VMs port. This can be achieved using
>> Neutron’s allowed-address-pairs flag in the port-update function. We
>> intend to make use of Kuryr’s existing IPAM functionality to request these
>> IPs from Neutron.
>>
>>
>>
>> *Asks*
>>
>> We wish to discuss the pros and cons.
>>
>> For example, containers exposure as proper neutron entities and the
>> utility of neutron’s allowed-address-pairs is not yet well understood.
>>
>>
>>
>> We also wish to understand if this approach is acceptable for kuryr?
>>
>>
>>
>>
>>
>> *EPA*
>>
>> The Enhanced Platform Awareness initiative is a continuous program to
>> enable fine-tuning of the platform for virtualized network functions.
>>
>> This is done by exposing the processor and platform capabilities through
>> the management and orchestration layers.
>>
>> When a virtual network function is instantiated by an Enhanced Platform
>> Awareness enabled orchestrator, the application requirements can be more
>> efficiently matched with the platform capabilities.
>>
>> http://itpeernetwork.intel.com/openstack-kilo-release-is-sha
>> ping-up-to-be-a-milestone-for-enhanced-platform-awareness/
>>
>> https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf
>>
>> https://www.brighttalk.com/webcast/12229/181563/epa-features
>> -in-openstack-kilo
>>
>>
>>
>>
>>
>> Regards,
>>
>> Ivan….
>>
>> --------------------------------------------------------------
>> Intel Research and Development Ireland Limited
>> Registered in Ireland
>> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
>> Registered Number: 308263
>>
>> This e-mail and any attachments may contain confidential material for the
>> sole use of the intended recipient(s). Any review or distribution by others
>> is strictly prohibited. If you are not the intended recipient, please
>> contact the sender and delete all copies.
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> --------------------------------------------------------------
>> Intel Research and Development Ireland Limited
>> Registered in Ireland
>> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
>> Registered Number: 308263
>>
>> This e-mail and any attachments may contain confidential material for the
>> sole use of the intended recipient(s). Any review or distribution by others
>> is strictly prohibited. If you are not the intended recipient, please
>> contact the sender and delete all copies.
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160914/074f666f/attachment.html>