On Mon, Apr 18, 2016 at 2:55 PM, Aaron Rosen <aaronoro...@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. > 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 ? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
