16:05:04 #startmeeting MD-SAL weekly call 16:05:04 Meeting started Tue May 27 16:05:04 2014 UTC. The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html. 16:05:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:05:04 The meeting name has been set to 'md_sal_weekly_call' 16:05:16 #topic status check 16:06:05 #info reviewing bugfixes/patches that have been merged 16:06:46 #link https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Weekly_Status this information will be logged here (thanks devinavery) 16:12:05 #link https://git.opendaylight.org/gerrit/#/q/status:open+project:yangtools+branch:master+topic:helium/api-clarity,n,z 16:12:13 thanks edwarnicke, you beat me to it 16:13:36 is the meeting being recorded ? 16:14:26 Madhu: I don’t know 16:14:43 thanks devinavery 16:16:31 #link https://git.opendaylight.org/gerrit/#/q/project:yangtools+branch:master+topic:helium/api-clarity,n,z link to see the work tony is doing around API documentation (w/o status:open per rovarga) 16:16:44 #topic blocking issues 16:18:29 #info adding one around stating triage/bug scrub meetings 16:18:42 #info flaviof will work on bug 1027 16:19:11 #topic what is preventing people from using the MD-SAL 16:20:12 #info devinavery suggests that we need things to focus on and one way to do that would be to put out a surveymonkey to figure out what to work on 16:20:32 colindixon: Robert V is testing/closing bug 1027. 16:20:34 #info edwarnicke says surveymonkey is great, but we also need to figure if people are willing to push on the things 16:20:43 flaviof: good to know 16:21:21 #info (from above) rovarga is testing/closing bug 1027 16:25:48 #topic tracking features/work 16:26:14 #info the general idea seems to be to track things as bugs/enhancements in bugzilla and see how that works 16:26:47 #info other suggestions were just using the mailing list or the ask.opendaylight.org page, but bugzilla for anchored discussion seemed to stick for now 16:27:10 #topic clustering work demo 16:27:37 colindixon: Many thanks for taking notes :) 16:27:59 #action devinavery will open a bug zilla ticket for each item in the "What preventing you from using MD-SAL?" list 16:29:41 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store Moiz starts by looking over the design posteder here 16:30:08 #info that design is loosely based on the APIC data store based on the presentation that dvorkinista presented a few weeks back 16:32:14 #info note that this meeting will be recorded, so you can watch the demo later 16:33:10 #info they created a simple client/server where clients can store messages on the server 16:35:09 #info when servers come up they read (from configuration passed by -Dakka.cluster.role on the CLI and in roles.conf/members.conf/shards.conf) what their roles are and thus determine what shards they need to host and create local actors for each shard 16:38:04 #info demonstrating replication (state migrated from server 1 to server 2) 16:38:34 #info demonstrating persistence, closing and relaunching causes state to be recovered 16:40:40 #info demonstrating more clustering features: (1) messages being replayed to servers when they come back from being down, (2) also failover to the highest-preference server 16:42:27 #topic looking through some of the code 16:43:23 #info messages defined in scala, like java, but the constructor fields essentially define the whole class 16:44:14 #info clustering-services is a shim on top of Akka cluster 16:45:19 #info processes messages in receive() method including MemberUp, MemberRemoved, UnreachableMember, etc. 16:48:24 #Info colindixon asks why we seem to be shimming MemberUp into MemberAvailable with no changes? Answer seems to be, we thought we might gain something by the layer of indirection, but if not, we can remove it later. 16:48:59 #info clustering service also has config utils used to read the config in and figure out which nodes should host which shards 16:49:37 #info server has a shard manager, shard replicator, and kv shard 16:50:17 #info shard manager reads config and creates an actor for each shard, these shards are actors implemented by kv shard to be key-value shards today 16:50:33 #info going forward, we can create different kinds of shards, k-v, tree, graph, etc. 16:55:01 #info KVShard basically just receives key,value pairs and stores them locally—it also has functionality around creating snapshots and handling replications 16:57:50 #info shard replicator watches things and sends replicated messages for others to store information 16:58:43 #info client code is really simple and sends 11 messages to be stored 16:59:24 #link https://git.opendaylight.org/gerrit/#/c/7427/ this code can be checked out from here 17:00:43 #info there’s also performance stuff in that patch 17:02:03 #link https://trello.com/b/7oW0V2Yl/opendaylight-clustering progress being tracked in trello if people want to help out 17:02:06 #endmeeting