Open Stack

On Tue, Mar 24, 2015 at 12:15 PM, Salvatore Orlando <sorlando at nicira.com>
wrote:

>
>
> 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
>

Hi, it's fine for me, romil's patch is a good step forward.


>
>
>> 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
>>
>>
>
> __________________________________________________________________________
> 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/6acdd43e/attachment.html>