<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 12:15 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 23 March 2015 at 14:49, Mathieu Rohon <span dir="ltr"><<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi romil,<br><br></div>I think the main purpose of this DB field is to maintain the compatibility in dataplane between OVS and LinuxBridge which, by default, don't use the same UDP port for VXLAN.<br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>It might be useful for a cloud admin which wants to run some nodes with LB and some others with OVS.<br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I feel like your patch proposal will enable this scenario if the tunnel_update() RPC message gets updated with the UDP port too.<br></div></div></blockquote><div><br></div></span><div>I have scanned a bit the ML2 code - to find out why we're storing configuration info into the server side database.</div><div>It seems the tunnel_sync RPC callback it actually acts as a relay for tunnel synchronisation messages from agents.</div><div>An agent notifies its tunnel information, these are stored into the server, and then the server propagates updated information about tunnels to all agents.</div><div>By storing the information in the DB we have a sort of guarantee against lost messages, as the whole tunnel info would be relayed again the next time an update comes up. So every agent will eventually receive the lost message (where eventually means "at some point before the end of the universe" and has nothing to do with eventual consistency).<br></div><div><br></div><div>While there might be questions about this approach, I don't think we have time and energy to look at it before the end of the release cycle. In my opinion if Romil's patch actually enable the scenario described by Mathieu then it might make sense to change the RPC interface to allow this. Otherwise, I don't think there's any urgency for squashing this change in Kilo.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Salvatore</div></font></span></div></div></div></blockquote><div><br></div><div>Hi, it's fine for me, romil's patch is a good step forward.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>Mathieu<br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Mar 23, 2015 at 11:40 AM, Romil Gupta <span dir="ltr"><<a href="mailto:romilgupta19@gmail.com" target="_blank">romilgupta19@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hello everyone,<div><br></div><div>There is regarding the following bug:</div><div><a href="https://bugs.launchpad.net/neutron/+bug/1373359" target="_blank">https://bugs.launchpad.net/neutron/+bug/1373359</a></div><div><br></div><div>May I know what is the significance of having the '<b>udp_port'</b> field in the  <b>'ml2_vxlan_endpoints</b>' table in Neutron DB, Do we have any plans in future that we could use this field for synchronization or any other purpose instead of simply keeping it in the DB.</div><div><br></div><div>The following patchset will fix the bug mentioned above,</div><div><a href="https://review.openstack.org/#/c/153891/" target="_blank">https://review.openstack.org/#/c/153891/</a></div><div><br></div><div>But the question still remains the same. Do we need to keep this field or we need to remove it? </div><span><font color="#888888"><div><div><br></div><div>-- <br></div><div><div dir="ltr"><b style="color:rgb(102,102,102)">Regards,</b><div><b style="color:rgb(102,102,102)">Romil <br></b><br></div></div></div>
</div></font></span></div>
<br></div></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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></blockquote></div><br></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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></blockquote></span></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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></blockquote></div><br></div></div>