[openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

Neil Jerram Neil.Jerram at metaswitch.com
Thu Dec 4 16:00:08 UTC 2014

Kevin Benton <blak111 at gmail.com> writes:

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

I was actually floating a slightly more radical option than that: the
idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does
absolutely _nothing_, not even create the TAP device.

(My pending Nova spec at https://review.openstack.org/#/c/130732/
proposes VIF_TYPE_TAP, for which Nova _does_ creates the TAP device, but
then does nothing else - i.e. exactly what you've described just above.
But in this email thread I was musing about going even further, towards
providing a platform for future networking experimentation where Nova
isn't involved at all in the networking setup logic.)

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

Thanks.  I'm not advocating that existing VIF types should be removed,
though - rather wondering if similar function could in principle be
implemented without Nova VIF plugging - or what that would take.

For example, suppose someone came along and wanted to implement a new
OVS-like networking infrastructure?  In principle could they do that
without having to enhance the Nova VIF driver code?  I think at the
moment they couldn't, but that they would be able to if VIF_TYPE_NOOP
(or possibly VIF_TYPE_TAP) was already in place.  In principle I think
it would then be possible for the new implementation to specify
VIF_TYPE_NOOP to Nova, and to provide a Neutron agent that does the kind
of configuration and vSwitch plugging that you've described above.

Does that sound correct, or am I missing something else?

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

Agreed - but thanks for clarifying the exact sequence of events.

I wonder if what I'm describing (either VIF_TYPE_NOOP or VIF_TYPE_TAP)
might fit as part of the "Nova-network/Neutron Migration" priority
that's just been announced for Kilo.  I'm aware that a part of that
priority is concerned with live migration, but perhaps it could also
include the goal of future networking work not having to touch Nova


More information about the OpenStack-dev mailing list