Open Stack

On 23 March 2015 at 14:49, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:

> Hi romil,
>
> 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.
>
It might be useful for a cloud admin which wants to run some nodes with LB
> and some others with OVS.
>

> I feel like your patch proposal will enable this scenario if the
> tunnel_update() RPC message gets updated with the UDP port too.
>

I have scanned a bit the ML2 code - to find out why we're storing
configuration info into the server side database.
It seems the tunnel_sync RPC callback it actually acts as a relay for
tunnel synchronisation messages from agents.
An agent notifies its tunnel information, these are stored into the server,
and then the server propagates updated information about tunnels to all
agents.
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).

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.

Salvatore


> Mathieu
>
> On Mon, Mar 23, 2015 at 11:40 AM, Romil Gupta <romilgupta19 at gmail.com>
> wrote:
>
>> Hello everyone,
>>
>> There is regarding the following bug:
>> https://bugs.launchpad.net/neutron/+bug/1373359
>>
>> May I know what is the significance of having the '*udp_port'* field in
>> the  *'ml2_vxlan_endpoints*' 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.
>>
>> The following patchset will fix the bug mentioned above,
>> https://review.openstack.org/#/c/153891/
>>
>> But the question still remains the same. Do we need to keep this field or
>> we need to remove it?
>>
>> --
>> *Regards,*
>>
>> *Romil *
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150324/e52e3204/attachment.html>