[ovs-dev] [PATCH RFC] ovn: distributed logical port for VM metadata access

Ben Pfaff blp at ovn.org
Thu Apr 14 21:47:26 UTC 2016


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?



More information about the dev mailing list