#opendaylight-meeting: MD-SAL weekly call

Meeting started by colindixon at 16:05:04 UTC (full logs).

Meeting summary

  1. status check (colindixon, 16:05:16)
    1. reviewing bugfixes/patches that have been merged (colindixon, 16:06:05)
    2. https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Weekly_Status this information will be logged here (thanks devinavery) (colindixon, 16:06:46)
    3. https://git.opendaylight.org/gerrit/#/q/status:open+project:yangtools+branch:master+topic:helium/api-clarity,n,z (edwarnicke, 16:12:05)
    4. 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) (colindixon, 16:16:31)

  2. blocking issues (colindixon, 16:16:44)
    1. adding one around stating triage/bug scrub meetings (colindixon, 16:18:29)
    2. flaviof will work on bug 1027 (colindixon, 16:18:42)

  3. what is preventing people from using the MD-SAL (colindixon, 16:19:11)
    1. 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 (colindixon, 16:20:12)
    2. edwarnicke says surveymonkey is great, but we also need to figure if people are willing to push on the things (colindixon, 16:20:34)
    3. (from above) rovarga is testing/closing bug 1027 (colindixon, 16:21:21)

  4. tracking features/work (colindixon, 16:25:48)
    1. the general idea seems to be to track things as bugs/enhancements in bugzilla and see how that works (colindixon, 16:26:14)
    2. other suggestions were just using the mailing list or the ask.opendaylight.org page, but bugzilla for anchored discussion seemed to stick for now (colindixon, 16:26:47)

  5. clustering work demo (colindixon, 16:27:10)
    1. ACTION: devinavery will open a bug zilla ticket for each item in the "What preventing you from using MD-SAL?" list (devinavery, 16:27:59)
    2. https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Architecture:Clustered_Data_Store Moiz starts by looking over the design posteder here (colindixon, 16:29:41)
    3. that design is loosely based on the APIC data store based on the presentation that dvorkinista presented a few weeks back (colindixon, 16:30:08)
    4. note that this meeting will be recorded, so you can watch the demo later (colindixon, 16:32:14)
    5. they created a simple client/server where clients can store messages on the server (colindixon, 16:33:10)
    6. 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 (colindixon, 16:35:09)
    7. demonstrating replication (state migrated from server 1 to server 2) (colindixon, 16:38:04)
    8. demonstrating persistence, closing and relaunching causes state to be recovered (colindixon, 16:38:34)
    9. 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 (colindixon, 16:40:40)

  6. looking through some of the code (colindixon, 16:42:27)
    1. messages defined in scala, like java, but the constructor fields essentially define the whole class (colindixon, 16:43:23)
    2. clustering-services is a shim on top of Akka cluster (colindixon, 16:44:14)
    3. processes messages in receive() method including MemberUp, MemberRemoved, UnreachableMember, etc. (colindixon, 16:45:19)
    4. 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. (colindixon, 16:48:24)
    5. clustering service also has config utils used to read the config in and figure out which nodes should host which shards (colindixon, 16:48:59)
    6. server has a shard manager, shard replicator, and kv shard (colindixon, 16:49:37)
    7. 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 (colindixon, 16:50:17)
    8. going forward, we can create different kinds of shards, k-v, tree, graph, etc. (colindixon, 16:50:33)
    9. KVShard basically just receives key,value pairs and stores them locally—it also has functionality around creating snapshots and handling replications (colindixon, 16:55:01)
    10. shard replicator watches things and sends replicated messages for others to store information (colindixon, 16:57:50)
    11. client code is really simple and sends 11 messages to be stored (colindixon, 16:58:43)
    12. https://git.opendaylight.org/gerrit/#/c/7427/ this code can be checked out from here (colindixon, 16:59:24)
    13. there’s also performance stuff in that patch (colindixon, 17:00:43)
    14. https://trello.com/b/7oW0V2Yl/opendaylight-clustering progress being tracked in trello if people want to help out (colindixon, 17:02:03)


Meeting ended at 17:02:06 UTC (full logs).

Action items

  1. devinavery will open a bug zilla ticket for each item in the "What preventing you from using MD-SAL?" list


Action items, by person

  1. devinavery
    1. devinavery will open a bug zilla ticket for each item in the "What preventing you from using MD-SAL?" list


People present (lines said)

  1. colindixon (43)
  2. odl_meetbot (3)
  3. edwarnicke (2)
  4. Madhu (2)
  5. devinavery (1)
  6. flaviof (1)


Generated by MeetBot 0.1.4.