Open Stack

Hi Kevin,

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.

Best Regards
Henry

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