Open Stack

On Mon, Sep 12, 2016 at 1:42 PM, Antoni Segura Puimedon
<celebdor at gmail.com> wrote:
> On Mon, Sep 12, 2016 at 1:29 PM, Coughlan, Ivan <ivan.coughlan at intel.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>