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

Russell Bryant russell at ovn.org
Fri Apr 15 21:12:08 UTC 2016


On Thu, Apr 14, 2016 at 5:47 PM, Ben Pfaff <blp at 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



More information about the dev mailing list