On Mon, Apr 11, 2016 at 03:35:58PM -0400, Ramu Ramamurthy wrote: > A new logical-port-type called "distributed" is introduced with this change. > > A distributed logical port is not bound to any chassis. An instance of > the distributed port is created as an ovs internal port at all chasses > where the datapath has at least 1 vif. VIFs on a chassis can communicate > with the locally created distributed port on the same chassis. A distributed > port cannot be reached remotely via tunnels or via localnet from other > logical ports on the logical switch. Unicast traffic originated from > external localnet VMs cannot reach the distributed port. > > The distributed logical port allows the implementation of services > in a logical switch that are available at the same IP,mac address on each > chassis to serve local VMs on that logical switch bound to that chassis. > The motivating usecase is the Openstack dhcp-based metadata > access which is described in detail below. > > Please suggest any feedback on a) the usecase, b) the approach suggested > here to implement it, c) any alternatives. If it makes sense > I can pursue this work further. > > Usecase - DHCP-based metadata access > > VMs (using cloudinit) use metadata access at the url http://169.254.169.254. > (https://cloudinit.readthedocs.org/en/latest/topics/datasources.html#ec2) > > In Openstack DHCP-based metadata access, the DHCP server advertizes a static > route > to the link-local address 169.254.169.254 pointing to the DHCP port's IP > address > using DHCP option 249. A neutron-metadata-proxy server listens on the DHCP > port > which is also aliased with the link local address 169.254.169.254, and > serves metadata requests from VMs. The metadata-proxy server extracts > the VMs IP address from the http request, and sets the "X-Forwarded-For" and > "X-Neutron-Network-Id" http headers, and forwards the request to the > neutron-metadata-agent which in turn forwards the request to nova. > > With proposed native-dhcp implementation in OVN, there is no need to run the > neutron-DHCP-agent in Openstack. Since DHCP-based metadata was implemented by > the dhcp-agent, A new approach is needed to implement the metadata-service.
This is an interesting proposal. The alternative, which strikes me as a terrible idea, would be to somehow implement a TCP/IP stack and HTTP server inside OVS. Does there need to be a single metadata server per hypervisor, or one per logical switch per hypervisor? I think that a lot of the commit message (include some bits that I snipped) should go into documentation. I feel like this needs to be properly evaluated by someone who understands OpenStack and Neutron better than me. Maybe Russell? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
