On Wed, Sep 14, 2016 at 7:10 AM, Liping Mao (limao) <[email protected]> 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 <[email protected]> > Reply-To: OpenStack List <[email protected]> > Date: 2016年9月13日 星期二 下午9:09 > To: OpenStack List <[email protected]> > > 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 <[email protected]> 写道： > > 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:[email protected] <[email protected]>] > *Sent:* Tuesday, September 13, 2016 12:56 PM > *To:* OpenStack Development Mailing List (not for usage questions) < > [email protected]> > *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 <[email protected]> 写道： > > > > *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- > shaping-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: [email protected]?subject:unsubscribe > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
