Open Stack

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