#opendaylight-meeting: kernel projects

Meeting started by rgoulding at 16:01:52 UTC (full logs).

Meeting summary

  1. agenda bashing (rgoulding, 16:02:01)
    1. https://bugs.opendaylight.org/show_bug.cgi?id=8839 (rgoulding, 16:02:13)
    2. JavaDoc discussion on odlparent-dev (rgoulding, 16:02:18)
    3. if time & interest: infrautils.MoreFutures.logFailure: https://git.opendaylight.org/gerrit/#/c/60207/ (rgoulding, 16:02:26)
    4. https://git.opendaylight.org/gerrit/#/c/60207/ (rgoulding, 16:02:34)
    5. if time & interest: infrautils.LogCaptureRule: https://git.opendaylight.org/gerrit/#/c/60204/ (rgoulding, 16:02:41)
    6. https://git.opendaylight.org/gerrit/#/c/60204/ (rgoulding, 16:02:47)

  2. Bug 8839 (rgoulding, 16:03:59)
    1. https://bugs.opendaylight.org/show_bug.cgi?id=8839 (rgoulding, 16:04:11)
    2. ACTION: Sai and Luis to let Atul Gosain know the NETCONF password encryption patch is being reverted to unblock the Carbon-SR1 release (rgoulding, 16:06:22)
    3. perhaps before we merge these sorts of patches we should rquire some sort of corresponding CSIT test (rgoulding, 16:07:24)
    4. ACTION: to test the encryption mechanism in master (rgoulding, 16:07:37)
    5. ACTION: tcere to +2 netconf encryption patch andemail releng team to merge the patch (rgoulding, 16:13:59)
    6. https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=921315511 Carbon SR1 Tracking spreadsheet (zxiiro, 16:14:00)

  3. carbon tracking (rgoulding, 16:14:16)
    1. Thanh is concerned about 8805 since he is unsure if thjey will require respin (rgoulding, 16:14:59)
    2. https://bugs.opendaylight.org/show_bug.cgi?id=8805 is not a blocker (rgoulding, 16:15:39)
    3. https://bugs.opendaylight.org/show_bug.cgi?id=8805 (rgoulding, 16:15:41)

  4. JavaDoc discussion on odlparent-dev (rgoulding, 16:16:15)
    1. https://lists.opendaylight.org/pipermail/odlparent-dev/2017-July/001215.html (rgoulding, 16:17:17)
    2. maven-javadoc-plugin and whether it is possible for us to deploy to some site? what mechanism would we use to deploy? (rgoulding, 16:17:43)
    3. zxiiro is unsure at the moment, but he recommends pushes the artifacts to nexus so we can deploy when we figure it out (rgoulding, 16:18:11)
    4. zxiiro if you have a deploy-site.xml, it will trigger jenkins to build the javadoc site (rgoulding, 16:18:28)
    5. https://nexus.opendaylight.org/content/sites/site/ Maven Site (zxiiro, 16:18:39)
    6. rovarga this is where the aggregate javadocs should be pushed out (rgoulding, 16:19:24)
    7. rovarga this runs aggregates recursively (rgoulding, 16:19:36)
    8. https://nexus.opendaylight.org/content/sites/site/org.opendaylight.odlparent/boron/maven-site.html current instructions for creating maven sites (zxiiro, 16:20:26)
    9. rovarga should we publish the javadocs by release train? (rgoulding, 16:23:53)
    10. then we can reverse proxy to the appropriate sites deployed on nexus (rgoulding, 16:26:38)
    11. zxiiro if we do it by version they only get released when we release a new version of ODL (rgoulding, 16:27:01)
    12. zxiiro if we update now it gets pushed out immediately since they are SNAPSHOT builds (rgoulding, 16:27:20)
    13. how much value is this worth? (rgoulding, 16:27:40)
    14. vorburger why do this every six months if we can do it every change (rgoulding, 16:27:56)
    15. bug fixes also include javadoc clarifications (rgoulding, 16:28:04)
    16. rovarga consistency of javadocs could become a problem if we do it per merge on SNAPSHOT builds (rgoulding, 16:28:24)
    17. vorburger on the branch it will still be the right versions, right? (rgoulding, 16:29:03)
    18. rovarga in cross project related javadoc changes you may have stale links (rgoulding, 16:29:53)
    19. vorburger is this a corner case? (rgoulding, 16:30:00)
    20. rovarga doesn’t have to be code related. javadocs have links that can break but not at compile time (rgoulding, 16:30:24)
    21. this is related to the “@link” style annotations (rgoulding, 16:30:32)
    22. vorburger says he would prefer having a site with broken links rather than not having the site at all (rgoulding, 16:31:03)
    23. zxirro we can rewrite maven sites at any time (rgoulding, 16:31:17)
    24. can we wipe the crud that gets accumulated over the release frame? (rgoulding, 16:32:54)
    25. it is possible (rgoulding, 16:33:03)
    26. job could be updated to do it automatically (rgoulding, 16:33:08)
    27. rovarga says the site replacement ought to be atomic (rgoulding, 16:33:58)
    28. zxiiro nexus only provides deploy mechanism, not move mechanism (rgoulding, 16:34:19)
    29. ACTION: vorburger to open a bug against releng/builder for wiping sites (rgoulding, 16:35:45)

  5. Karaf 4 Update (rgoulding, 16:39:51)
    1. ecelgp thinks that it is slow how projects are coming into integration/distribution (rgoulding, 16:40:39)
    2. but it is happening still (rgoulding, 16:40:45)
    3. two questions 1) karaf4 issue with NETCONF and dependent project (rgoulding, 16:41:43)
    4. 2) Bug 8824 - NETCONF request hangs when rpc-rply has invalid xml (rgoulding, 16:42:33)
    5. https://bugs.opendaylight.org/show_bug.cgi?id=8803 (rgoulding, 16:43:26)
    6. rovarga need karaf log for this (rgoulding, 16:44:53)
    7. rovarga if it truly is a deadlock/busy wait then we need a thread dump (rgoulding, 16:45:04)
    8. rovarga until it is further analyzed we shouldn’t move it from openflowplugin to netconf because we don’t have enough information to reproduce or analyze (rgoulding, 16:45:31)
    9. still one issue with config subsystem features added to integration/distribution (rgoulding, 16:46:02)
    10. projects that sitll have dependency on NETCONF need to hold off from joining integration/distribution unitl it resolves this issue (rgoulding, 16:46:20)
    11. rovarga asks ecelgp if it affects nitrogen only (rgoulding, 16:46:55)
    12. ecelgp it affects nitrogen only (rgoulding, 16:47:08)
    13. ACTION: ecelgp to push karaf.log or thread dump depending on whetherCPU spikes to 100% (rgoulding, 16:47:26)

  6. if time & interest: infrautils.MoreFutures.logFailure: https://git.opendaylight.org/gerrit/#/c/60207/ (rgoulding, 16:47:34)
    1. https://git.opendaylight.org/gerrit/#/c/60207/ (rgoulding, 16:47:40)
    2. vorburger pushed this patch for netvirt, but wants to make sure it is the right way and that there is nto a simpler way to log if anything went wrong when doing Transaction.submit() and ignore the returned future (rgoulding, 16:48:25)
    3. rovarga why are you ignoring the Future? That would mean you have no recovery scenarios (rgoulding, 16:49:31)
    4. vorburger claims that most of the DS interactions don’t have recovery scenarios (rgoulding, 16:49:56)
    5. vorburger a warning in the log is a lot better than not getting anything at all (rgoulding, 16:50:11)
    6. rovarga would be much happier with people explicitly adding these (rgoulding, 16:50:30)
    7. if you are doing high performance stuff you probably don’t want to be using this thing and adding your own callbacks on top of it? (rgoulding, 16:50:59)
    8. if you are adding in either recovery or succes on top of this logging, then it will degrade performance (rgoulding, 16:51:29)
    9. vorburger javadoc should contain a big fat bold statement saying that you should be doing this on your own isntead of using this (rgoulding, 16:51:49)
    10. skitt instead of converting all the current code to use this new wrapper that adds a logging handler, make that explicit in the code everywhere that needs to have error handling/recovery (rgoulding, 16:52:47)
    11. vorburger that assumes people know how to do recovery code (rgoulding, 16:53:10)
    12. vorburger, they haven’t been in 3-4 years (rgoulding, 16:53:19)
    13. skitt says this will hide the real problem and no one will actually know what they are supposed to do (rgoulding, 16:53:40)
    14. rovarga the long term strategy should probably involve having an annotation to submit and ensure the return value is not ignored (rgoulding, 16:54:23)
    15. this will at least trigger an eclipse warning (rgoulding, 16:54:38)
    16. skitt this may have people put related operations into a single transactionchain instead of many small transactions (rgoulding, 16:55:07)
    17. vorburger thinks this may be a bit optimistic (rgoulding, 16:55:29)
    18. rovarga this is really useful for single transactions, but less useful for TransactionChain(s) (rgoulding, 16:55:52)
    19. rovarga you can hook an error listener to a TransactionChain for error recovery (rgoulding, 16:56:08)
    20. vorburger many thousands of line of code does not use TransactionChain(s) (rgoulding, 16:56:20)
    21. skitt even if there is deprecation warning or javadoc, they will ignore it and use it because it exists (rgoulding, 16:56:42)
    22. it implies it is "approved" (rgoulding, 16:56:47)
    23. skitt in genius/netvirt you are firing off so many small transactions that it is nearly hard to recover anyway (rgoulding, 16:57:16)
    24. vorburger thinks that it will just make the codelook ugly instead of actually influencing people to do it correctly (rgoulding, 16:57:47)
    25. vorburger is there a middle ground by dismissing the MoreFutures facade (which hides some of this) (rgoulding, 16:58:48)
    26. skitt feels like that this is a waste oftime (rgoulding, 16:59:09)
    27. vorburger the code to add a callback is like 5 lines instead of one utility line (rgoulding, 16:59:28)


Meeting ended at 17:02:26 UTC (full logs).

Action items

  1. Sai and Luis to let Atul Gosain know the NETCONF password encryption patch is being reverted to unblock the Carbon-SR1 release
  2. to test the encryption mechanism in master
  3. tcere to +2 netconf encryption patch andemail releng team to merge the patch
  4. vorburger to open a bug against releng/builder for wiping sites
  5. ecelgp to push karaf.log or thread dump depending on whetherCPU spikes to 100%


Action items, by person

  1. vorburger
    1. vorburger to open a bug against releng/builder for wiping sites
  2. UNASSIGNED
    1. Sai and Luis to let Atul Gosain know the NETCONF password encryption patch is being reverted to unblock the Carbon-SR1 release
    2. to test the encryption mechanism in master
    3. tcere to +2 netconf encryption patch andemail releng team to merge the patch
    4. ecelgp to push karaf.log or thread dump depending on whetherCPU spikes to 100%


People present (lines said)

  1. rgoulding (91)
  2. odl_meetbot (4)
  3. zxiiro (3)
  4. vorburger (1)


Generated by MeetBot 0.1.4.