Kevin Benton <blak...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
