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? In your example above you picked 10.0.0.100. I'm wondering if there is a more flexible way to handle this. It seems to me like this ip needs to be selected a head of time to be able to correctly distribute the host route before the instance has configured it's self with dhcp. I'm thinking that just picking the first free ip_address in the subnet and using that might be fine as long as there is a way to be able to dynamically update this after the fact if the user wants to use that same address for something else. I'm thinking in the case of someone deploying a heat template with predefined addresses for everything how we can avoid this conflict (maybe this doesn't matter much though and people are okay changing there static assignments or don't do that).
An alternative solution (which has the same problem about picking the ip address to use) 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? On Fri, Apr 15, 2016 at 4:49 PM, Ramu Ramamurthy <ramu.ramamur...@gmail.com> wrote: > > > > neutron-ovn-metadata would be something we maintain in our OpenStack > plugin > > repo (networking-ovn), right? > > > > Russell, Thanks for your review and feedback, > > neutron-ovn-metadata would be maintained in networking-ovn repo. > > > 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 > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
