[openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?
henry4hly at gmail.com
Wed Dec 10 07:48:30 UTC 2014
Does it make sense to introduce "GeneralvSwitch MD", working with
VIF_TYPE_TAP? It just do very simple port bind just like OVS and
bridge. Then anyone can implement their backend and agent without
patch neutron drivers.
On Fri, Dec 5, 2014 at 4:23 PM, Kevin Benton <blak111 at gmail.com> wrote:
> I see the difference now.
> The main concern I see with the NOOP type is that creating the virtual
> interface could require different logic for certain hypervisors. In that
> case Neutron would now have to know things about nova and to me it seems
> like that's slightly too far the other direction.
> On Thu, Dec 4, 2014 at 8:00 AM, Neil Jerram <Neil.Jerram at metaswitch.com>
>> 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
> Kevin Benton
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev