17:07:23 <colindixon> #startmeeting
17:07:23 <odl_meetbot> Meeting started Mon Apr 14 17:07:23 2014 UTC.  The chair is colindixon. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:07:23 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:07:58 <colindixon> #topic Reviewing the Cisco/Insieme APIC controller's clustering and state management
17:08:16 <colindixon> #info similar to MD-SAL in the datastore design
17:08:47 <colindixon> #info core idea was that you don't want require network admin to be a DB expert as well
17:09:12 <colindixon> #info General DB (or K-V) store isn't going to solve things
17:10:42 <colindixon> #info this is because, there aren't good DBs for storing, subscribing to, and manipulating trees
17:11:22 <colindixon> #topic it's all about the trees
17:12:26 <colindixon> #info claim: everything is pretty much a tree, this is different from tables or other organization, e.g., OVSDB, SQL, etc.
17:12:58 <colindixon> #info APIC uses a managed object tree
17:13:34 <colindixon> #info everything is a classed object, objects are hierarchically organized, objects can be subclassed
17:16:28 <colindixon> #info a given object has one and only one parent (except the root which has no parent)
17:17:00 <colindixon> #info queries
17:17:06 <colindixon> #topic queries
17:17:52 <colindixon> #info can query by type (class or superclass), properties, unique name, scoping by subtree, or a combination of all of them
17:19:13 <colindixon> #info this whole thing is a very nice fit for RESTful interfaces
17:20:22 <colindixon> #info comparisons to the MD-SAL model
17:20:34 <colindixon> #topic comparisons to the MD-SAL model
17:20:53 <colindixon> #info this is very similar to the MD-SAL, but there are some key differences
17:21:10 <colindixon> #info RESTCONF doesn't allow class-based queries, for instance
17:21:43 <colindixon> #info this doesn't necessarily work with YANG, this is a bit more general, e.g., cross-references are not allowed in YANG
17:24:44 <colindixon> #info 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
17:27:06 <colindixon> #topic sharding
17:27:36 <colindixon> #info the total tree is shared into subtrees with the root of subtrees being called "context roots"
17:28:05 <colindixon> #info the shards are then mapped onto nodes using consistent hashing (as in DHTs)
17:29:35 <colindixon> #info sharding is static (defined in the model by explicitly naming the context root)
17:33:44 <colindixon> #info the sharding is currently always based on the hierarchy, not based on properties of nodes or anything else
17:35:20 <colindixon> #info 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
17:35:50 <colindixon> #info mike dvorkin notes that this is a trade-off you *have* to make if you're going to shard. colindixon agrees.
17:37:40 <colindixon> #topic shard replication
17:38:02 <colindixon> #info shards are replicated 3 times: one is the "leader" and two are "followers"
17:41:01 <colindixon> #info Madhu asks how the different sections of this presentation are related, and how this is related to the MD-SAL
17:41:58 <colindixon> #info 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
17:44:05 <colindixon> #info 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
17:46:40 <colindixon> #topic wider discussion of data stores
17:46:51 <colindixon> #info GiovanniMeo asks why not infinispan
17:47:13 <colindixon> #info colindixon says it's trees and consistency trade-offs seemingly being strange in Infinispan
17:48:28 <colindixon> #info jan medved says (and colindixon agrees) that we really need this for helium (at least with one good implementation)
17:48:52 <colindixon> #info jan would like to have many implementations which we could then test and evaluate
17:49:24 <colindixon> #info colindixon says that would be great, but at some point practicalities will likely insist that we don't have 4 different implementations
17:49:31 <colindixon> #topic back to sharding replication
17:54:09 <colindixon> #info leaders and followers are statically placed, if a leader fails, a follower steps up
17:55:35 <colindixon> #info 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
17:57:17 <colindixon> #info no new followers or leaders are added in response to the failure as the assumption is that it will recover soon
17:58:05 <colindixon> #topic service/app model
18:02:16 <colindixon> #info the general effort is to co-located code (for services) with their data based on shards
18:02:27 <colindixon> #topic scheduling next meeting
18:03:34 <colindixon> #info we will continue this and the Akka discussion in meetings later this week with details to be sent to the mailing list
18:03:38 <colindixon> #endmeeting