#opendaylight-meeting: kernel projects

Meeting started by rgoulding at 15:59:14 UTC (full logs).

Meeting summary

  1. agenda bashing (rgoulding, 15:59:18)
    1. odlparent-3.1.2 timing (rgoulding, 15:59:25)
    2. odlparent 3.2.0 (rgoulding, 15:59:30)
    3. odlparent-4.0.0: karaf 4.2.X in Neon? (rgoulding, 15:59:43)
    4. clustering topics contd. from netvirt call (rgoulding, 16:08:45)

  2. odlparent 3.1.2 (rgoulding, 16:09:04)
    1. skitt has a multipatch running and release notes prepared (rgoulding, 16:09:17)
    2. rovarga to submit patch to disable SFT on Java9+ (rgoulding, 16:09:39)
    3. one more patch is expected (rgoulding, 16:09:44)
    4. then it should be released (rgoulding, 16:09:48)

  3. odlparent 3.2.0 (rgoulding, 16:09:55)
    1. Fluorine or beyond? (rgoulding, 16:10:40)
    2. the integration window has gone (rgoulding, 16:10:46)
    3. vorburger is not pushing for Fluorine (rgoulding, 16:10:56)
    4. live with this for Fl (rgoulding, 16:11:17)

  4. odlparent 4.0.0 (rgoulding, 16:11:26)
    1. includes karaf-4.2.X (rgoulding, 16:11:31)
    2. expect to be in Neon (rgoulding, 16:11:36)
    3. guava 26 / 27 (rgoulding, 16:11:48)
    4. what is the compatibility? (rgoulding, 16:11:57)
    5. Java 9 requires karaf 4.2.X (rgoulding, 16:12:24)
    6. given the timeline, skitt brings up looking at java 10 for Neon (rgoulding, 16:12:35)
    7. rovarga unsure about how to spin the java upgrade (rgoulding, 16:12:52)
    8. in sept java 11 will hit (rgoulding, 16:13:04)
    9. oracle will pick up java 11 as LTS (rgoulding, 16:13:11)
    10. how will we handle runtime compat? (rgoulding, 16:13:19)
    11. as well as source code compat going forward (rgoulding, 16:13:25)
    12. so we can run verify jobs with java 9/10 to get some meaningful output so we can even think about upgrade (rgoulding, 16:13:55)
    13. 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 (rgoulding, 16:14:38)
    14. vorburger brings up how much variability we wnat to support going forward (rgoulding, 16:14:57)
    15. rovarga brings up the fact that not too many projects are actually using JVM internals particular to a particular JVM flavor/version (rgoulding, 16:16:06)
    16. so we may not have an explosion in our testing matrix (rgoulding, 16:16:20)
    17. w/ JVM releases every 6 months, the compat matrix will explode (rgoulding, 16:17:06)
    18. we will need some strategy to prune jvms to not get stuck (rgoulding, 16:17:19)
    19. rovarga is in favor of keeping the test matrix as small as possible (rgoulding, 16:17:49)
    20. vorburger expresses desire to avoid overhead by picking too many (rgoulding, 16:19:04)
    21. we need a release that supports 2 JDKs simultaneously before we bump the requirements (rgoulding, 16:19:25)
    22. telcos generally require a longer support for two releases in order to qualify new java releases (rgoulding, 16:19:52)
    23. locking down into a potentially broken jdk needs to be avoided (rgoulding, 16:20:06)

  5. clustering cont’d from netvirt call (rgoulding, 16:21:56)
    1. skitt there was discussion in netvirt call surrounding clustering (rgoulding, 16:22:29)
    2. there are some issues with 3 node csit for netvirt/controller (rgoulding, 16:22:40)
    3. want to focus on fixing those bugs (rgoulding, 16:22:50)
    4. 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) (rgoulding, 16:24:10)
    5. for point #2, there are a number of questions brought up on best-practices (rgoulding, 16:24:25)
    6. i.e., what are the impacts of having a transaction on 1 shard versus many shards. (rgoulding, 16:24:40)
    7. how can we deal with code that writes to config/operational in the same transaction? (rgoulding, 16:24:54)
    8. split up application logic so it is writing to only config or operational (rgoulding, 16:25:16)
    9. 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 (rgoulding, 16:25:37)
    10. they are not an atomic entity (rgoulding, 16:25:46)
    11. early patch set to enforce config/operational split: https://git.opendaylight.org/gerrit/73041 (skitt, 16:26:07)
    12. you should be writing to config DS and then write to operational once the config write has completed (rgoulding, 16:26:15)
    13. there hasn’t been a use case brought up for this (rgoulding, 16:26:47)
    14. rovarga has asked several times, and no one has come back with a use case that actually requires this functionality (rgoulding, 16:27:08)
    15. ACTION: daya to come back with use case for this in the future (rgoulding, 16:27:23)
    16. example patchset under discussion, with blind config/operational split: https://git.opendaylight.org/gerrit/72871 (skitt, 16:27:26)
    17. operational state needs to be derived from configuration state separately (rgoulding, 16:28:18)
    18. ACTION: daya to ask the original authors why they decided to write the code this way (rgoulding, 16:29:17)
    19. this may just be a misuse of the technology due to lack of understanding (rgoulding, 16:29:45)
    20. and not an true use case (rgoulding, 16:29:51)
    21. 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 (rgoulding, 16:31:17)
    22. that architecture was based on ODL, so shoudl be possible (rgoulding, 16:31:37)
    23. https://git.opendaylight.org/gerrit/#/c/73041/ (rgoulding, 16:31:56)
    24. https://tools.ietf.org/html/rfc8342 NMDA (rovarga_, 16:32:03)
    25. another thing that NETVIRT team has been thinking about for a while is how to deal with shards (rgoulding, 16:34:09)
    26. 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 (rgoulding, 16:35:14)
    27. tpantelis and rovarga bring up that this is the producer API (rgoulding, 16:35:23)
    28. https://github.com/opendaylight/mdsal/blob/master/dom/mdsal-dom-api/src/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeProducerFactory.java (rgoulding, 16:36:17)
    29. see also https://github.com/opendaylight/mdsal/blob/master/dom/mdsal-dom-api/src/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeProducer.java (rgoulding, 16:38:08)
    30. there is some revisiting that is needed to this code, but this is basically what Stephen was wondering about (rgoulding, 16:40:42)
    31. these add a performance boost as well (rgoulding, 16:45:31)

  6. tell-based protocol (rgoulding, 16:47:42)
    1. what is the status of this? (rgoulding, 16:47:51)
    2. daya asks if it is mature enough to move to the tell-based protocol or at least start exploring the migration (rgoulding, 16:48:17)
    3. luis brings up the fact that he tried in openflowplugin and that he had to disable it because it iddnt improve performance (rgoulding, 16:48:44)
    4. tpantelis brings up that it won’t necessary improve perforamnce, its more around resiliency (rgoulding, 16:48:56)
    5. i.e., eliminate possibility of AskTimeoutException (rgoulding, 16:49:11)
    6. somebody needs to pick this up and drive benchmarking and testing (rgoulding, 16:50:01)
    7. in Carbon this increased performance, decreased in Nitrogen+ when Luis tested. (rgoulding, 16:50:16)
    8. we need to ensure that all patches were moved from Carbon into Nitrogen+ (look at git logs) (rgoulding, 16:50:40)
    9. rovarga brings up that bgpcep with a single node performed markedly better (rgoulding, 16:52:54)
    10. Luis asks if this applies to single node to? (rgoulding, 16:53:18)
    11. it does (rgoulding, 16:53:20)
    12. https://lists.opendaylight.org/pipermail/controller-dev/2016-January/011401.html (rovarga_, 17:00:30)


Meeting ended at 17:00:59 UTC (full logs).

Action items

  1. daya to come back with use case for this in the future
  2. daya to ask the original authors why they decided to write the code this way


People present (lines said)

  1. rgoulding (88)
  2. odl_meetbot (5)
  3. skitt (5)
  4. rovarga_ (4)
  5. vorburger (2)


Generated by MeetBot 0.1.4.