On Tue, Sep 13, 2016 at 5:26 PM, Liping Mao (limao) <[email protected]> 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 <[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-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: [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
