16:01:54 <rgoulding> #startmeeting kernel projects
16:01:54 <odl_meetbot> Meeting started Tue Oct 24 16:01:54 2017 UTC.  The chair is rgoulding. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:01:54 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:54 <odl_meetbot> The meeting name has been set to 'kernel_projects'
16:02:10 <rgoulding> #topic agenda bashing
16:03:52 <rgoulding> #info merged/modified patches in the last week
16:04:02 <rgoulding> #topic merged/modified patches in the last 7 days
16:04:39 <rgoulding> #undo
16:04:39 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x16ba450>
16:05:00 <rgoulding> #topic How to have a single shard for operational and config, but with/without persistence?
16:05:09 <rgoulding> #info this topic comes from last week but no RH folks were on the call
16:05:19 <rgoulding> #info there was an offline email surrounding this question
16:07:30 <rgoulding> @link https://lists.opendaylight.org/pipermail/controller-dev/2017-October/013958.html
16:07:36 <rgoulding> #undo
16:07:36 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x12b7a90>
16:07:38 <rgoulding> #link https://lists.opendaylight.org/pipermail/controller-dev/2017-October/013958.html
16:08:20 <rgoulding> #info skitt says there are a bunch of a places in netvirt that tries to manipulate config and oper simulateously which is pretty bad
16:08:32 <rgoulding> #info skitt this probably needs to be fixed in the downstream
16:08:49 <rgoulding> #info the solution is to split the writes up
16:09:26 <rgoulding> #info skitt if you don’t care about scaleout it tends to be easier to know where your leaders are and direct requests towards that specific node
16:10:48 <rgoulding> #info this can be done through configuring the module shards and is considered a deployment concern
16:11:28 <rgoulding> #info the way the term shard is used in ODL vs other distributed systems;  you can usually use per key-range shard vs per yang tree
16:12:05 <rgoulding> #info rovarga the trouble is basically that you are comparing databases that arekey/value pairs that can be represented by a table.  the problem is…. how do you shard a tree?
16:12:55 <rgoulding> #info part of the CDT design is that you can look at IID prefix to determine nested trees.  thus you can shard the tree by hierarchy
16:13:08 <rgoulding> #info rather than using hashing / key-ranges
16:13:27 <rgoulding> #info for that to work you need some sort of consistent key hashing
16:13:40 <rgoulding> #info specifically in the case of lists
16:13:47 <rgoulding> #info this can be done but is not something we have done at this time
16:14:06 <rgoulding> #info can have a “shard” per list-entry item
16:14:18 <rgoulding> #info you cannot currently have a shard for a range of keys within a list right now
16:14:30 <rgoulding> #info that is a question of designing and implementing it rather than architecture and design
16:14:33 <rgoulding> #info it can be done but hasnt
16:14:57 <rgoulding> #info skitt where is the mapping done between shards and the tree
16:15:03 <rgoulding> #undo
16:15:03 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x16ae5d0>
16:15:13 <rgoulding> #info skitt where is the mapping done between shards and the tree?
16:15:38 <rgoulding> #info CDS takes care of module-based shards.  MDSAL component is used for prefix-based shards in DOM Broker impl or somewhere?
16:16:15 <rgoulding> #info it is called ShardedDomDataTree
16:18:54 <rovarga_> #link https://wiki.opendaylight.org/view/MD-SAL:Boron:Conceptual_Data_Tree
16:20:35 <rgoulding> #topic merged/pending patches in last 7 days
16:21:12 <rgoulding> #info rovarga many changes in yang-model-api
16:21:40 <rgoulding> #info one in particular is Bug-9265
16:21:49 <rgoulding> #info this is done to ensure that leaf does not have a null value, but rather Empty value
16:22:10 <rgoulding> #info there will be work needed in mdsal mostly, and other downstreams probably don’t have to worry so much
16:22:40 <rgoulding> #info rovarga will communicate via email some of the changes as they near completion
16:24:02 <vrpolak> yes. https://git.opendaylight.org/gerrit/63329
16:24:27 <rgoulding> #link https://git.opendaylight.org/gerrit/63329
16:26:07 <rgoulding> #link https://bugs.opendaylight.org/show_bug.cgi?id=9189
16:29:15 <rgoulding> #info this may only affect integration/distribution
16:33:39 <rgoulding> #info this is just a convenience and can probably be done in integration/distribution or the existing code might be migrated off CSS?
16:34:02 <rgoulding> #info waiting for a “writable” local data store
16:35:59 <rgoulding> #info combo of RPC + blueprint could be used.  or “.cfg” file using ManagedService or something
16:38:34 <rgoulding> #link https://wiki.opendaylight.org/view/Using_Blueprint#Application_configuration
16:39:46 <rgoulding> #topic DiagStatus Expose Dataastore health to applications via infrautils.diagstatus
16:39:49 <rgoulding> #link https://lists.opendaylight.org/pipermail/controller-dev/2017-October/thread.html
16:39:59 <rgoulding> #info look at things related to “Expose Dataastore health to applications via infrautils.diagstatus"
16:40:26 <rgoulding> #info varying philosophies on “mature” vs “incubation” stuff here
16:41:19 <rgoulding> #info tpantelis raises the piont that this diagstatus mechanism is a small bundle
16:41:27 <rgoulding> #info it is a small component and completely new
16:41:48 <rgoulding> #info rovarga raises the point… “are we going to do stable features ever?"
16:42:08 <rgoulding> #info rovarga says that if you pull it into the DS, you cannot call the controller feature a “Stable Feature"
16:42:23 <rgoulding> #info since stable features require dependencies to be stable as well
16:42:32 <rgoulding> #info if it is just JMX, it can live anywhere
16:42:53 <rgoulding> #info for example, why can’t we use YANG model DTO(s) there instead of hand-written ones
16:43:06 <rgoulding> #info rovarga raises the point that this goes against the desire to do stable features
16:43:24 <rgoulding> #info rovarga asks whether this is still happening and whether it is completely shot from the radar
16:44:26 <rgoulding> #info can we have infrautils become “mature” then do the change?
16:47:11 <rgoulding> #info if infrautils just depends on odlparent, it needs to use custom DTOs instead of modeled DTOs
16:49:24 <rgoulding> #info this means that data becomes somewhat siloed
16:56:13 <rgoulding> #info skitt: this comes down to inability to make these small projects like lldp in Nitrogen etc.
16:56:26 <rgoulding> #info becomes a hierarchy question
16:57:20 <rgoulding> #info it is something needed to query th eTSC
16:57:28 <rgoulding> #info i.e., how do we have smaller scoped projects in ODL
16:58:07 <rgoulding> #info then something that would have ended up in yangtools/infratutils is to develop it in a consumer, have tests, the API has been used extensively, then you pull it out and it becomes its own small project
16:58:19 <rgoulding> #info that could be an ideal solution for diagstatus etc.
17:01:56 <rgoulding> #info put into infrautils using JMX API
17:02:08 <rgoulding> #info separate bundle or something
17:05:23 <rovarga_> #link https://wiki.opendaylight.org/view/ODL_Root_Parent:Mature_Graduation_Proposal
17:09:22 <rgoulding> #endmeeting