#opendaylight-clustering: clustering_hackers

Meeting summary

1. 1. Agenda: OpenFlow Clustering, Bug Review, Commit Review (moizer, 15:58:25)
   2. WebEx URL : https://cisco.webex.com/cisco/e.php?MTID=mde353b902dff47fa53db1b989597942b (moizer, 15:59:17)
   
   
2. OpenFlow Clustering (moizer, 16:22:48)
   1. http://conntrack-tools.netfilter.org/ (catohornet, 17:03:25)
   2. 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. (moizer, 17:30:26)
   3. 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 (moizer, 17:31:34)
   4. 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 (moizer, 17:32:47)
   5. 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 (moizer, 17:34:02)
   6. due to conflicting modifications (moizer, 17:35:10)
   7. rovarga acknowledges problem (moizer, 17:35:27)
   8. anil, kamal, rovarga agree that we need to have a way of notifying apps of a shard role change (moizer, 17:36:21)
   9. 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 (moizer, 17:37:06)
   10. we do not have consensus on the exact approach to take for openflow clustering (moizer, 17:38:34)
   11. as a first step kamal/anil will come up with a service to share shard state (moizer, 17:39:02)
   12. other discussion may continue over email/irc (moizer, 17:39:19)
   13. ACTION: moizer to follow up with Ed to understand design options with remote data change notifications and how to safely introduce it (moizer, 17:40:32)
   
   
3. Enable CDS as default (moizer, 17:40:53)
   1. moizer - we are good from security perspective because we bind to localhost by default - this will make remote attacks not possible (moizer, 17:41:47)
   2. from a performance perspective - we resolved the issue of the hiccup experienced in transaction chain with PUT for large number of transactions (moizer, 17:44:06)
   3. moizer/tpantelis opinion performance is ok enough to make CDS default (moizer, 17:44:38)
   4. this gives us some time to soak and find issues with clustering (moizer, 17:44:54)
   5. jmedved concerned that for bgp the clustering performance is 4 times lower than imds and that we need to continue with the performance optimizations (moizer, 17:45:37)
   6. moizer/tpanelis - agree (moizer, 17:45:57)
   7. markmozolewski was blocked on doing performance test for 3-node clustering because of a deployment bug - which is fixed now (moizer, 17:47:27)

Action items

1. moizer to follow up with Ed to understand design options with remote data change notifications and how to safely introduce it

Action items, by person

1. moizer
   1. moizer to follow up with Ed to understand design options with remote data change notifications and how to safely introduce it

People present (lines said)

1. moizer (27)
2. odl_meetbot (3)
3. catohornet (3)