On Mon, Sep 12, 2016 at 1:29 PM, Coughlan, Ivan <[email protected]> wrote: > > > 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?
Thanks Ivan, adding discussion about this to the weekly IRC meeting. Maybe it's a bit tight for all the participants to get comfortable enough with the specifics to take a decision today, but let's bring the topic to the table and give an answer during this week. > > > > > > 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 > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
