Open Stack

What you are proposing sounds very reasonable. If I understand correctly,
the idea is to make Nova just create the TAP device and get it attached to
the VM and leave it 'unplugged'. This would work well and might eliminate
the need for some drivers. I see no reason to block adding a VIF type that
does this.

However, there is a good reason that the VIF type for some OVS-based
deployments require this type of setup. The vSwitches are connected to a
central controller using openflow (or ovsdb) which configures forwarding
rules/etc. Therefore they don't have any agents running on the compute
nodes from the Neutron side to perform the step of getting the interface
plugged into the vSwitch in the first place. For this reason, we will still
need both types of VIFs.


> 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.

This is backwards. The tap device name is derived from the port ID, so the
port has already been created in Neutron at that point. It is just unbound.
The steps are roughly as follows: Nova calls neutron for a port, Nova
creates/plugs VIF based on port, Nova updates port on Neutron, Neutron
binds the port and notifies agent/plugin/whatever to finish the plumbing,
Neutron notifies Nova that port is active, Nova unfreezes the VM.

None of that should be affected by what you are proposing. The only
difference is that your Neutron agent would also perform the 'plugging'
operation.

For your second point, scanning the integration bridge for new ports is
currently used now, but that's an implementation detail of the reference
OVS driver. It doesn't block your work directly since OVS wouldn't use your
NOOP VIF type anyway.


Cheers,
Kevin Benton

On Wed, Dec 3, 2014 at 8:08 AM, Neil Jerram <Neil.Jerram at metaswitch.com>
wrote:

> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141203/b1afaeec/attachment.html>