Hi there. I've been looking into a tricky point, and hope I can succeed in expressing it clearly here...
I believe it is the case, even when using a committedly Neutron-based networking implementation, that Nova is still involved a little bit in the networking setup logic. Specifically I mean the plug() and unplug() operations, whose implementations are provided by *VIFDriver classes for the various possible hypervisors. For example, for the libvirt hypervisor, LibvirtGenericVIFDriver typically implements plug() by calling create_tap_dev() to create the TAP device, and then plugging into some form of L2 bridge. Does this logic actually have to be in Nova? For a Neutron-based networking implementation, it seems to me that it should also be possible to do this in a Neutron agent (obviously running on the compute node concerned), and that - if so - that would be preferable because it would enable more Neutron-based experimentation without having to modify any Nova code. Specifically, therefore, I wonder if we could/should add a "do-nothing" value to the set of Nova VIF types (VIF_TYPE_NOOP?), and implement plug()/unplug() for that value to do nothing at all, leaving all setup to the Neutron agent? And then hopefully it should never be necessary to introduce further Nova VIF type support ever again... Am I missing something that really makes that not fly? Two possible objections occurs to me, as follows, but I think they're both surmountable. 1. When the port is created in the Neutron DB, and handled (bound etc.) by the plugin and/or mechanism driver, the TAP device name is already present at that time. I think this is still OK because Neutron knows anyway what the TAP device name _will_ be, even if the actual TAP device hasn't been created yet. 2. With some agent implementations, there isn't a direct instruction, from the plugin to the agent, to say "now look after this VM / port". Instead the agents polls the OS for new TAP devices appearing. Clearly, then, if there isn't something other than the agent that creates the TAP device, any logic in the agent will never be triggered. This is certain a problem. For new networking experimentation, however, we can write agent code that is directly instructed by the plugin, and hence (a) doesn't need to poll (b) doesn't require the TAP device to have been previously created by Nova - which I'd argue is preferable. Thoughts? (FYI my context is that I've been working on a networking implementation where the TAP device to/from a VM should _not_ be plugged into a bridge - and for that I've had to make a Nova change even though my team's aim was to do the whole thing in Neutron. I've proposed a spec for the Nova change that plugs a TAP interface without bridging it (https://review.openstack.org/#/c/130732/), but that set me wondering about this wider question of whether such Nova changes should still be necessary...) Many thanks, Neil _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
