On Tue, Mar 24, 2015 at 12:15 PM, Salvatore Orlando <[email protected]> wrote:
> > > On 23 March 2015 at 14:49, Mathieu Rohon <[email protected]> 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 <[email protected]> >> 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: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
