#opendaylight-meeting Meeting

Meeting started by colindixon at 17:07:23 UTC (full logs).

Meeting summary

  1. Reviewing the Cisco/Insieme APIC controller's clustering and state management (colindixon, 17:07:58)
    1. similar to MD-SAL in the datastore design (colindixon, 17:08:16)
    2. core idea was that you don't want require network admin to be a DB expert as well (colindixon, 17:08:47)
    3. General DB (or K-V) store isn't going to solve things (colindixon, 17:09:12)
    4. this is because, there aren't good DBs for storing, subscribing to, and manipulating trees (colindixon, 17:10:42)

  2. it's all about the trees (colindixon, 17:11:22)
    1. claim: everything is pretty much a tree, this is different from tables or other organization, e.g., OVSDB, SQL, etc. (colindixon, 17:12:26)
    2. APIC uses a managed object tree (colindixon, 17:12:58)
    3. everything is a classed object, objects are hierarchically organized, objects can be subclassed (colindixon, 17:13:34)
    4. a given object has one and only one parent (except the root which has no parent) (colindixon, 17:16:28)
    5. queries (colindixon, 17:17:00)

  3. queries (colindixon, 17:17:06)
    1. can query by type (class or superclass), properties, unique name, scoping by subtree, or a combination of all of them (colindixon, 17:17:52)
    2. this whole thing is a very nice fit for RESTful interfaces (colindixon, 17:19:13)
    3. comparisons to the MD-SAL model (colindixon, 17:20:22)

  4. comparisons to the MD-SAL model (colindixon, 17:20:34)
    1. this is very similar to the MD-SAL, but there are some key differences (colindixon, 17:20:53)
    2. RESTCONF doesn't allow class-based queries, for instance (colindixon, 17:21:10)
    3. this doesn't necessarily work with YANG, this is a bit more general, e.g., cross-references are not allowed in YANG (colindixon, 17:21:43)
    4. some discussion seems to point to the fact that this cross-referencing should be possible in YANG as well, but might take a bit of work (colindixon, 17:24:44)

  5. sharding (colindixon, 17:27:06)
    1. the total tree is shared into subtrees with the root of subtrees being called "context roots" (colindixon, 17:27:36)
    2. the shards are then mapped onto nodes using consistent hashing (as in DHTs) (colindixon, 17:28:05)
    3. sharding is static (defined in the model by explicitly naming the context root) (colindixon, 17:29:35)
    4. the sharding is currently always based on the hierarchy, not based on properties of nodes or anything else (colindixon, 17:33:44)
    5. this means that you want to make sure that your hierarchy is going to match your query patterns so that queries tend to stay in the same shard (colindixon, 17:35:20)
    6. mike dvorkin notes that this is a trade-off you *have* to make if you're going to shard. colindixon agrees. (colindixon, 17:35:50)

  6. shard replication (colindixon, 17:37:40)
    1. shards are replicated 3 times: one is the "leader" and two are "followers" (colindixon, 17:38:02)
    2. Madhu asks how the different sections of this presentation are related, and how this is related to the MD-SAL (colindixon, 17:41:01)
    3. jan medved and mike dvorkin say basically, this is looking at how to model hierarchical data, and store it efficiently in a clustered sense, it's very similar to how the MD-SAL stores data (colindixon, 17:41:58)
    4. a longer discussion between jan, Madhu, and GiovanniMeo about how to build these things and how this works with Akka, vs. the MD-SAL in-memory data store vs. Infiinspan vs. APIC data store (colindixon, 17:44:05)

  7. wider discussion of data stores (colindixon, 17:46:40)
    1. GiovanniMeo asks why not infinispan (colindixon, 17:46:51)
    2. colindixon says it's trees and consistency trade-offs seemingly being strange in Infinispan (colindixon, 17:47:13)
    3. jan medved says (and colindixon agrees) that we really need this for helium (at least with one good implementation) (colindixon, 17:48:28)
    4. jan would like to have many implementations which we could then test and evaluate (colindixon, 17:48:52)
    5. colindixon says that would be great, but at some point practicalities will likely insist that we don't have 4 different implementations (colindixon, 17:49:24)

  8. back to sharding replication (colindixon, 17:49:31)
    1. leaders and followers are statically placed, if a leader fails, a follower steps up (colindixon, 17:54:09)
    2. the assumption, however, is that the leader being down is temporary and that when it comes up things will be moved back to it as soon as it catches up (colindixon, 17:55:35)
    3. no new followers or leaders are added in response to the failure as the assumption is that it will recover soon (colindixon, 17:57:17)

  9. service/app model (colindixon, 17:58:05)
    1. the general effort is to co-located code (for services) with their data based on shards (colindixon, 18:02:16)

  10. scheduling next meeting (colindixon, 18:02:27)
    1. we will continue this and the Akka discussion in meetings later this week with details to be sent to the mailing list (colindixon, 18:03:34)


Meeting ended at 18:03:38 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. colindixon (48)
  2. odl_meetbot (2)


Generated by MeetBot 0.1.4.