Open Stack

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
code?

Regards,
        Neil