<div dir="ltr">What would the port binding operation do in this case? Just mark the port as bound and nothing else?</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 10, 2014 at 12:48 AM, henry hly <span dir="ltr"><<a href="mailto:henry4hly@gmail.com" target="_blank">henry4hly@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kevin,<br>
<br>
Does it make sense to introduce "GeneralvSwitch MD", working with<br>
VIF_TYPE_TAP? It just do very simple port bind just like OVS and<br>
bridge. Then anyone can implement their backend and agent without<br>
patch neutron drivers.<br>
<br>
Best Regards<br>
<span class="HOEnZb"><font color="#888888">Henry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Dec 5, 2014 at 4:23 PM, Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>> wrote:<br>
> I see the difference now.<br>
> The main concern I see with the NOOP type is that creating the virtual<br>
> interface could require different logic for certain hypervisors. In that<br>
> case Neutron would now have to know things about nova and to me it seems<br>
> like that's slightly too far the other direction.<br>
><br>
> On Thu, Dec 4, 2014 at 8:00 AM, Neil Jerram <<a href="mailto:Neil.Jerram@metaswitch.com">Neil.Jerram@metaswitch.com</a>><br>
> wrote:<br>
>><br>
>> Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>> writes:<br>
>><br>
>> > What you are proposing sounds very reasonable. If I understand<br>
>> > correctly, the idea is to make Nova just create the TAP device and get<br>
>> > it attached to the VM and leave it 'unplugged'. This would work well<br>
>> > and might eliminate the need for some drivers. I see no reason to<br>
>> > block adding a VIF type that does this.<br>
>><br>
>> I was actually floating a slightly more radical option than that: the<br>
>> idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does<br>
>> absolutely _nothing_, not even create the TAP device.<br>
>><br>
>> (My pending Nova spec at <a href="https://review.openstack.org/#/c/130732/" target="_blank">https://review.openstack.org/#/c/130732/</a><br>
>> proposes VIF_TYPE_TAP, for which Nova _does_ creates the TAP device, but<br>
>> then does nothing else - i.e. exactly what you've described just above.<br>
>> But in this email thread I was musing about going even further, towards<br>
>> providing a platform for future networking experimentation where Nova<br>
>> isn't involved at all in the networking setup logic.)<br>
>><br>
>> > However, there is a good reason that the VIF type for some OVS-based<br>
>> > deployments require this type of setup. The vSwitches are connected to<br>
>> > a central controller using openflow (or ovsdb) which configures<br>
>> > forwarding rules/etc. Therefore they don't have any agents running on<br>
>> > the compute nodes from the Neutron side to perform the step of getting<br>
>> > the interface plugged into the vSwitch in the first place. For this<br>
>> > reason, we will still need both types of VIFs.<br>
>><br>
>> Thanks.  I'm not advocating that existing VIF types should be removed,<br>
>> though - rather wondering if similar function could in principle be<br>
>> implemented without Nova VIF plugging - or what that would take.<br>
>><br>
>> For example, suppose someone came along and wanted to implement a new<br>
>> OVS-like networking infrastructure?  In principle could they do that<br>
>> without having to enhance the Nova VIF driver code?  I think at the<br>
>> moment they couldn't, but that they would be able to if VIF_TYPE_NOOP<br>
>> (or possibly VIF_TYPE_TAP) was already in place.  In principle I think<br>
>> it would then be possible for the new implementation to specify<br>
>> VIF_TYPE_NOOP to Nova, and to provide a Neutron agent that does the kind<br>
>> of configuration and vSwitch plugging that you've described above.<br>
>><br>
>> Does that sound correct, or am I missing something else?<br>
>><br>
>> >> 1 .When the port is created in the Neutron DB, and handled (bound<br>
>> > etc.)<br>
>> > by the plugin and/or mechanism driver, the TAP device name is already<br>
>> > present at that time.<br>
>> ><br>
>> > This is backwards. The tap device name is derived from the port ID, so<br>
>> > the port has already been created in Neutron at that point. It is just<br>
>> > unbound. The steps are roughly as follows: Nova calls neutron for a<br>
>> > port, Nova creates/plugs VIF based on port, Nova updates port on<br>
>> > Neutron, Neutron binds the port and notifies agent/plugin/whatever to<br>
>> > finish the plumbing, Neutron notifies Nova that port is active, Nova<br>
>> > unfreezes the VM.<br>
>> ><br>
>> > None of that should be affected by what you are proposing. The only<br>
>> > difference is that your Neutron agent would also perform the<br>
>> > 'plugging' operation.<br>
>><br>
>> Agreed - but thanks for clarifying the exact sequence of events.<br>
>><br>
>> I wonder if what I'm describing (either VIF_TYPE_NOOP or VIF_TYPE_TAP)<br>
>> might fit as part of the "Nova-network/Neutron Migration" priority<br>
>> that's just been announced for Kilo.  I'm aware that a part of that<br>
>> priority is concerned with live migration, but perhaps it could also<br>
>> include the goal of future networking work not having to touch Nova<br>
>> code?<br>
>><br>
>> Regards,<br>
>>         Neil<br>
><br>
><br>
><br>
><br>
> --<br>
> Kevin Benton<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>