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

Aaron Rosen aaronorosen at gmail.com
Tue Apr 19 19:18:37 UTC 2016


Hi Ramu,


On Tue, Apr 19, 2016 at 8:12 AM, Ramu Ramamurthy <ramu.ramamurthy at gmail.com>
wrote:

> On Mon, Apr 18, 2016 at 2:55 PM, Aaron Rosen <aaronorosen at gmail.com>
> wrote:
> > I like this idea as well.
> >
> > The one question I have with is is how we should determine which ip
> address
> > to select for the 'distributed' port?
>
> Aaron, Thanks for your review, and feedback.
>
> We can use the dhcp-port (and its IP address) for the distributed-port.
>
> The current native-dhcp proposal
> (http://openvswitch.org/pipermail/dev/2016-April/069787.html)
> assumes that a dhcp-server ip-address "server_id" is defined on the subnet.
>
> action=(dhcp_offer(offerip = 10.0.0.2, router = 10.0.0.1,
> server_id = 10.0.0.2, mtu = 1300, lease_time = 3600,
>
> For openstack, This means that a DHCP port has been created on that
> subnet in neutron.
> In the absence of a dhcp-agent, the neutron-ovn-plugin would have to
> auto-create the
> dhcp-port in neutron upon creation of a subnet, and then use that
> port's IP address as
> the "server_id" when it programs the "dhcp-options"
> column of the Logical_Switch table.
>
> The pros of the distributed-port approach is that a) HA is not needed,
> b) it runs the existing
> neutron-metadata-proxy/neutron-metadata-agent as-is, c) In the future,
> we could remove the
> neutron-metadata-agent also, by (nova-compute) configuring the
> instance-id and tenant-id as external-ids
> of the VM's ovs interface - hence not need to run any neutron-agents at
> all.
> The drawbacks include creation of namespaces and metadata-proxy
> processes on each hypervisor.
>
>
> Cool, makes sense to me.


> > If we want to avoid creating the network name spaces and
> > running the http proxy on each hypervisor is if we took a similar
> approach
> > that openstack uses for handling dhcp/metadata requests.
> > When a subnet is created we could have the neutron-ovn-plugin notify a
> > metadata agent which would create a port on the given subnet for the
> logical
> > network. Then, to get instances to route its metadata traffic to this
> > logical port we could have ovn distribute an additional host-route via
> dhcp
> > (using option 121).  Similar to what you are proposing.
> >
> >
> > I.e:  So for example if someone created a network/subnet.
> >
> > In the ovn plugin we can signal the metadata agent to create a port on
> that
> > network.  Then, for every port that is created on this network we would
> > distribute a hostroute of 169.254.169.254/32 via <metadata-port>; Then,
> > we'd have the metadata agent just run there which would answer these meta
> > data requests and route them back.
> >
> > One down side to this solution is that this metadata agent would need to
> be
> > made HA in some way. In your current solution if the metadata agent
> crashes
> > or something the failure is isolated to the hypervisor. That said, this
> type
> > of HA seems like it can be implemented in at least an active passive
> > solution easily enough.
> >
> > Thoughts?
> >
>
> Your proposal is an alternative solution - which involves changes only to
> the
> neutron components  (and no changes in ovn ?). Would there be only one
> modified neutron-metadata-agent in an active-passive configuration serving
> all
> the VMs ? If there are multiple agents, would you need agent-scheduling to
> assign networks to agents ?
>
> Could you share more details of the approach ?
>


Right, with this approach I don't believe we would need any additional
changes in ovn besides the ability to specify host routes via dhcp.

For this solution we'd need to modify the neutron-metadata-agent to work in
this way. Currently, it has this functionality though it's coupled together
with the dhcp-agent (which we wouldn't want). In order to support HA you
would need to run multiple agents and the HA would use a similar
agent-scheduling method that neutron currently uses to map dhcp-agents to
networks. Also, the HA for this would need to be implemented as
active-passive I believe.

Personally, I do prefer your solution as the HA solution is more elegant as
it runs on each HV. That said, if having the namespaces on the hypervisor
nodes is a deal breaker than this would be an alternative solution to that.



More information about the dev mailing list