15:59:14 <rgoulding> #startmeeting kernel projects
15:59:14 <odl_meetbot> Meeting started Tue Jun 19 15:59:14 2018 UTC.  The chair is rgoulding. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:59:14 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:59:14 <odl_meetbot> The meeting name has been set to 'kernel_projects'
15:59:18 <rgoulding> #topic agenda bashing
15:59:25 <rgoulding> #info odlparent-3.1.2 timing
15:59:30 <rgoulding> #info odlparent 3.2.0
15:59:43 <rgoulding> #info odlparent-4.0.0:  karaf 4.2.X in Neon?
16:05:37 <rgoulding> skitt: planning to join?
16:05:40 <rgoulding> vorburger: likewise?
16:05:51 <skitt> rgoulding, yes
16:05:55 <vorburger> skitt: yes
16:06:01 <skitt> rgoulding, tomp too
16:06:14 <vorburger> skitt: dropping off netvirt call now
16:08:45 <rgoulding> #info clustering topics contd. from netvirt call
16:09:04 <rgoulding> #topic odlparent 3.1.2
16:09:17 <rgoulding> #info skitt has a multipatch running and release notes prepared
16:09:39 <rgoulding> #info rovarga to submit patch to disable SFT on Java9+
16:09:44 <rgoulding> #info one more patch is expected
16:09:48 <rgoulding> #info then it should be released
16:09:55 <rgoulding> #topic odlparent 3.2.0
16:10:16 <rgoulding> #info fluroine?  beyond?
16:10:33 <rgoulding> #undo
16:10:33 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2d4ad10>
16:10:40 <rgoulding> #info Fluorine or beyond?
16:10:46 <rgoulding> #info the integration window has gone
16:10:56 <rgoulding> #info vorburger is not pushing for Fluorine
16:11:17 <rgoulding> #info live with this for Fl
16:11:26 <rgoulding> #topic odlparent 4.0.0
16:11:31 <rgoulding> #info includes karaf-4.2.X
16:11:36 <rgoulding> #info expect to be in Neon
16:11:41 <rgoulding> #info guave 26 or 27
16:11:44 <rgoulding> #undo
16:11:44 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2d632d0>
16:11:48 <rgoulding> #info guava 26 / 27
16:11:57 <rgoulding> #info what is the compatibility?
16:12:24 <rgoulding> #info Java 9 requires karaf 4.2.X
16:12:35 <rgoulding> #info given the timeline, skitt brings up looking at java 10 for Neon
16:12:52 <rgoulding> #info rovarga unsure about how to spin the java upgrade
16:13:04 <rgoulding> #info in sept java 11 will hit
16:13:11 <rgoulding> #info oracle will pick up java 11 as LTS
16:13:19 <rgoulding> #info how will we handle runtime compat?
16:13:25 <rgoulding> #info as well as source code compat going forward
16:13:55 <rgoulding> #info so we can run verify jobs with java 9/10 to get some meaningful output so we can even think about upgrade
16:14:38 <rgoulding> #info java9/10 compat is needed for Neon timeframe, as well as enabling a full developer environment on top of it.  However, we should require java 8 compat, according to skitt
16:14:57 <rgoulding> #info vorburger brings up how much variability we wnat to support going forward
16:16:06 <rgoulding> #info rovarga brings up the fact that not too many projects are actually using JVM internals particular to a particular JVM flavor/version
16:16:20 <rgoulding> #info so we may not have an explosion in our testing matrix
16:17:06 <rgoulding> #info w/ JVM releases every 6 months, the compat matrix will explode
16:17:19 <rgoulding> #info we will need some strategy to prune jvms to not get stuck
16:17:49 <rgoulding> #info rovarga is in favor of keeping the test matrix as small as possible
16:19:04 <rgoulding> #info vorburger expresses desire to avoid overhead by picking too many
16:19:25 <rgoulding> #info we need a release that supports 2 JDKs simultaneously before we bump the requirements
16:19:52 <rgoulding> #info telcos generally require a longer support for two releases in order to qualify new java releases
16:20:06 <rgoulding> #info locking down into a potentially broken jdk needs to be avoided
16:21:56 <rgoulding> #topic clustering cont’d from netvirt call
16:22:29 <rgoulding> #info skitt there was discussion in netvirt call surrounding clustering
16:22:40 <rgoulding> #info there are some issues with 3 node csit for netvirt/controller
16:22:50 <rgoulding> #info want to focus on fixing those bugs
16:24:10 <rgoulding> #info plan is to tackle things on two angles.  1) look at actual failures that are understandable/reproducible.  fix in targeted manner.  2) figure out the bad practices in code wrt clustering behavior (how transactions are built, etc.) and figure out ways to prevent making these same mistakes in the future (maybe APIs can be improved)
16:24:25 <rgoulding> #info for point #2, there are a number of questions brought up on best-practices
16:24:40 <rgoulding> #info i.e., what are the impacts of having a transaction on 1 shard versus many shards.
16:24:54 <rgoulding> #info how can we deal with code that writes to config/operational in the same transaction?
16:25:16 <rgoulding> #info split up application logic so it is writing to only config or operational
16:25:37 <rgoulding> #info rovarga writing config/operational at the same time has been deprecated for 4 years and it is going away.  it does not make any sense to do so
16:25:46 <rgoulding> #info they are not an atomic entity
16:26:07 <skitt> #link early patch set to enforce config/operational split: https://git.opendaylight.org/gerrit/73041
16:26:15 <rgoulding> #info you should be writing to config DS and then write to operational once the config write has completed
16:26:47 <rgoulding> #info there hasn’t been a use case brought up for this
16:27:08 <rgoulding> #info rovarga has asked several times, and no one has come back with a use case that actually requires this functionality
16:27:23 <rgoulding> #action daya to come back with use case for this in the future
16:27:26 <skitt> #link example patchset under discussion, with blind config/operational split: https://git.opendaylight.org/gerrit/72871
16:28:18 <rgoulding> #info operational state needs to be derived from configuration state separately
16:29:17 <rgoulding> #action daya to ask the original authors why they decided to write the code this way
16:29:45 <rgoulding> #info this may just be a misuse of the technology due to lack of understanding
16:29:50 * rovarga_ bets ^^^ is the case here :)
16:29:51 <rgoulding> #info and not an true use case
16:30:06 * skitt wouldn't bet against rovarga_
16:31:17 <rgoulding> #info rovarga brings up that if we plan to stay current with ietf network data store architecture, we must treat the data stores as separate entitites
16:31:37 <rgoulding> #info that architecture was based on ODL, so shoudl be possible
16:31:56 <rgoulding> #link https://git.opendaylight.org/gerrit/#/c/73041/
16:32:03 <rovarga_> #link https://tools.ietf.org/html/rfc8342 NMDA
16:34:09 <rgoulding> #info another thing that NETVIRT team has been thinking about for a while is how to deal with shards
16:35:14 <rgoulding> #info skitt poses question how hard it would be to have something that says, I want a transaction, and I’m going to be reading and writing from these subtrees
16:35:23 <rgoulding> #info tpantelis and rovarga bring up that this is the producer API
16:36:17 <rgoulding> #link https://github.com/opendaylight/mdsal/blob/master/dom/mdsal-dom-api/src/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeProducerFactory.java
16:38:08 <rgoulding> #link see also https://github.com/opendaylight/mdsal/blob/master/dom/mdsal-dom-api/src/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeProducer.java
16:40:42 <rgoulding> #info there is some revisiting that is needed to this code, but this is basically what Stephen was wondering about
16:45:31 <rgoulding> #info these add a performance boost as well
16:47:42 <rgoulding> #topic tell-based protocol
16:47:51 <rgoulding> #info what is the status of this?
16:48:17 <rgoulding> #info daya asks if it is mature enough to move to the tell-based protocol or at least start exploring the migration
16:48:44 <rgoulding> #info luis brings up the fact that he tried in openflowplugin and that he had to disable it because it iddnt improve performance
16:48:56 <rgoulding> #info tpantelis brings up that it won’t necessary improve perforamnce, its more around resiliency
16:49:11 <rgoulding> #info i.e., eliminate possibility of AskTimeoutException
16:50:01 <rgoulding> #info somebody needs to pick this up and drive benchmarking and testing
16:50:16 <rgoulding> #info in Carbon this increased performance, decreased in Nitrogen+ when Luis tested.
16:50:40 <rgoulding> #info we need to ensure that all patches were moved from Carbon into Nitrogen+ (look at git logs)
16:52:54 <rgoulding> #info rovarga brings up that bgpcep with a single node performed markedly better
16:53:18 <rgoulding> #info Luis asks if this applies to single node to?
16:53:20 <rgoulding> #info it does
17:00:30 <rovarga_> #link https://lists.opendaylight.org/pipermail/controller-dev/2016-January/011401.html
17:00:37 <rovarga_> companion to producer/consumer
17:00:59 <rgoulding> #endmeeting