On Thu, Apr 14, 2016 at 5:47 PM, Ben Pfaff <b...@ovn.org> wrote: > 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?
neutron-ovn-metadata would be something we maintain in our OpenStack plugin repo (networking-ovn), right? I like this proposal. It suggests adding only the minimal amount of support needed from OVN itself to enable us to get our OpenStack-specific job done. This is much better than anything I had thought of. Thank you! -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
