15:57:34 <moizer> #startmeeting clustering_hackers
15:57:34 <odl_meetbot> Meeting started Tue Mar  3 15:57:34 2015 UTC.  The chair is moizer. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:57:34 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:57:34 <odl_meetbot> The meeting name has been set to 'clustering_hackers'
15:58:25 <moizer> #info Agenda: OpenFlow Clustering, Bug Review, Commit Review
15:59:17 <moizer> #info WebEx URL : https://cisco.webex.com/cisco/e.php?MTID=mde353b902dff47fa53db1b989597942b
16:22:48 <moizer> #topic OpenFlow Clustering
17:00:02 <catohornet> Question: This use case sounds similar to Connection Tracking. Would this work the same way?
17:01:47 <moizer> catohornet - Not familiar with Connection Tracking
17:02:59 <catohornet> The Vyatta router used it as an HA solution along with VRRP.
17:03:25 <catohornet> http://conntrack-tools.netfilter.org/
17:29:06 <moizer> Ok catohornet - will check it out
17:30:26 <moizer> #info Anil needs a way to know which shard (possibly inventory) is the leader in the cluster so that he can make a switch master on that node. This is assuming a full mesh topology.
17:31:34 <moizer> #info Ed believes the right way to solve this is to use remote data change notifications and applications should use elections to figure out a leader amongst themselves
17:32:47 <moizer> #info moizer notes that remote data change notifications are turned off by default because our current applications are not written with the assumption that there are multiple instances of that app running
17:34:02 <moizer> #info The consequence of turning on remote data change notifications is that multiple instances of the app will react to the same notification and will in turn try to do an action which may corrupt data
17:35:10 <moizer> #info due to conflicting modifications
17:35:27 <moizer> #info rovarga acknowledges problem
17:36:21 <moizer> #info anil, kamal, rovarga agree that we need to have a way of notifying apps of a shard role change
17:37:06 <moizer> #info rovarga says we need to have apps turned on and off based on shard leadership change but is concerned that apps may not shutdown gracefully
17:38:34 <moizer> #info we do not have consensus on the exact approach to take for openflow clustering
17:39:02 <moizer> #info as a first step kamal/anil will come up with a service to share shard state
17:39:19 <moizer> #info other discussion may continue over email/irc
17:40:32 <moizer> #action moizer to follow up with Ed to understand design options with remote data change notifications and how to safely introduce it
17:40:53 <moizer> #topic Enable CDS as default
17:41:47 <moizer> #info moizer - we are good from security perspective because we bind to localhost by default - this will make remote attacks not possible
17:44:06 <moizer> #info from a performance perspective - we resolved the issue of the hiccup experienced in transaction chain with PUT for large number of transactions
17:44:38 <moizer> #info moizer/tpantelis opinion performance is ok enough to make CDS default
17:44:54 <moizer> #info this gives us some time to soak and find issues with clustering
17:45:37 <moizer> #info jmedved concerned that for bgp the clustering performance is 4 times lower than imds and that we need to continue with the performance optimizations
17:45:57 <moizer> #info moizer/tpanelis - agree
17:47:27 <moizer> #info markmozolewski was blocked on doing performance test for 3-node clustering because of a deployment bug - which is fixed now
17:47:51 <moizer> #endmeeting