On Mon, Sep 12, 2016 at 9:17 PM, Hongbin Lu <[email protected]> wrote:
> Ivan, > > Thanks for the proposal. From Magnum's point of view, this proposal > doesn't seem to require to store neutron/rabbitmq credentials in tenant VMs > which is more desirable. I am looking forward to the PoC. > Hogbin, Can you please elaborate on this will not require to store neutron credentials? For example in libnetwork case, neutron's commands like "show_port" and "update_port" will still need to be invoked from inside VM. Overall I liked this approach given its simplicity over vlan-aware-vms. -VikasC > > Best regards, > Hongbin > > On Mon, Sep 12, 2016 at 7:29 AM, 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? >> >> >> >> >> >> *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:unsubscrib >> e >> 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
