On Mon, Sep 12, 2016 at 1:42 PM, Antoni Segura Puimedon <[email protected]> wrote: > 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?
My vote is that it is acceptable to work on introducing such mode to kuryr-libnetwork (and later to kuryr-kubernetes). Could we get a link to the current PoC and set a meeting for an upstreaming plan? > > 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
