Open Stack

On Tue, Sep 13, 2016 at 5:26 PM, Liping Mao (limao) <limao at cisco.com> wrote:

> 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.
>
Vikas:

Can you please elaborate "maybe just disable port-security can be one of
the choice. then do not need allowed address pairs in this case" ?

Are you suggesting a solution where by disabling port security, each
container can have its own security group? Would you mind please explaining
a bit more for me ?


>
> 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:unsubscribe
> 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/0625cde5/attachment.html>