====================================== #opendaylight-meeting: kernel projects ====================================== Meeting started by rgoulding at 16:01:52 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-meeting/2017/kernel_projects/opendaylight-meeting-kernel_projects.2017-07-11-16.01.log.html . Meeting summary --------------- * agenda bashing (rgoulding, 16:02:01) * LINK: https://bugs.opendaylight.org/show_bug.cgi?id=8839 (rgoulding, 16:02:13) * JavaDoc discussion on odlparent-dev (rgoulding, 16:02:18) * if time & interest: infrautils.MoreFutures.logFailure: https://git.opendaylight.org/gerrit/#/c/60207/ (rgoulding, 16:02:26) * LINK: https://git.opendaylight.org/gerrit/#/c/60207/ (rgoulding, 16:02:34) * if time & interest: infrautils.LogCaptureRule: https://git.opendaylight.org/gerrit/#/c/60204/ (rgoulding, 16:02:41) * LINK: https://git.opendaylight.org/gerrit/#/c/60204/ (rgoulding, 16:02:47) * Bug 8839 (rgoulding, 16:03:59) * LINK: https://bugs.opendaylight.org/show_bug.cgi?id=8839 (rgoulding, 16:04:11) * 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) * perhaps before we merge these sorts of patches we should rquire some sort of corresponding CSIT test (rgoulding, 16:07:24) * ACTION: to test the encryption mechanism in master (rgoulding, 16:07:37) * ACTION: tcere to +2 netconf encryption patch andemail releng team to merge the patch (rgoulding, 16:13:59) * LINK: https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspHBNxKI_9XugJp-6Qbbw20Omk/edit#gid=921315511 Carbon SR1 Tracking spreadsheet (zxiiro, 16:14:00) * carbon tracking (rgoulding, 16:14:16) * Thanh is concerned about 8805 since he is unsure if thjey will require respin (rgoulding, 16:14:59) * https://bugs.opendaylight.org/show_bug.cgi?id=8805 is not a blocker (rgoulding, 16:15:39) * LINK: https://bugs.opendaylight.org/show_bug.cgi?id=8805 (rgoulding, 16:15:41) * JavaDoc discussion on odlparent-dev (rgoulding, 16:16:15) * LINK: https://lists.opendaylight.org/pipermail/odlparent-dev/2017-July/001215.html (rgoulding, 16:17:17) * 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) * 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) * zxiiro if you have a deploy-site.xml, it will trigger jenkins to build the javadoc site (rgoulding, 16:18:28) * LINK: https://nexus.opendaylight.org/content/sites/site/ Maven Site (zxiiro, 16:18:39) * rovarga this is where the aggregate javadocs should be pushed out (rgoulding, 16:19:24) * rovarga this runs aggregates recursively (rgoulding, 16:19:36) * LINK: https://nexus.opendaylight.org/content/sites/site/org.opendaylight.odlparent/boron/maven-site.html current instructions for creating maven sites (zxiiro, 16:20:26) * rovarga should we publish the javadocs by release train? (rgoulding, 16:23:53) * then we can reverse proxy to the appropriate sites deployed on nexus (rgoulding, 16:26:38) * zxiiro if we do it by version they only get released when we release a new version of ODL (rgoulding, 16:27:01) * zxiiro if we update now it gets pushed out immediately since they are SNAPSHOT builds (rgoulding, 16:27:20) * how much value is this worth? (rgoulding, 16:27:40) * vorburger why do this every six months if we can do it every change (rgoulding, 16:27:56) * bug fixes also include javadoc clarifications (rgoulding, 16:28:04) * rovarga consistency of javadocs could become a problem if we do it per merge on SNAPSHOT builds (rgoulding, 16:28:24) * vorburger on the branch it will still be the right versions, right? (rgoulding, 16:29:03) * rovarga in cross project related javadoc changes you may have stale links (rgoulding, 16:29:53) * vorburger is this a corner case? (rgoulding, 16:30:00) * rovarga doesn’t have to be code related. javadocs have links that can break but not at compile time (rgoulding, 16:30:24) * this is related to the “@link” style annotations (rgoulding, 16:30:32) * vorburger says he would prefer having a site with broken links rather than not having the site at all (rgoulding, 16:31:03) * zxirro we can rewrite maven sites at any time (rgoulding, 16:31:17) * can we wipe the crud that gets accumulated over the release frame? (rgoulding, 16:32:54) * it is possible (rgoulding, 16:33:03) * job could be updated to do it automatically (rgoulding, 16:33:08) * rovarga says the site replacement ought to be atomic (rgoulding, 16:33:58) * zxiiro nexus only provides deploy mechanism, not move mechanism (rgoulding, 16:34:19) * ACTION: vorburger to open a bug against releng/builder for wiping sites (rgoulding, 16:35:45) * Karaf 4 Update (rgoulding, 16:39:51) * ecelgp thinks that it is slow how projects are coming into integration/distribution (rgoulding, 16:40:39) * but it is happening still (rgoulding, 16:40:45) * two questions 1) karaf4 issue with NETCONF and dependent project (rgoulding, 16:41:43) * 2) Bug 8824 - NETCONF request hangs when rpc-rply has invalid xml (rgoulding, 16:42:33) * LINK: https://bugs.opendaylight.org/show_bug.cgi?id=8803 (rgoulding, 16:43:26) * rovarga need karaf log for this (rgoulding, 16:44:53) * rovarga if it truly is a deadlock/busy wait then we need a thread dump (rgoulding, 16:45:04) * 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) * still one issue with config subsystem features added to integration/distribution (rgoulding, 16:46:02) * projects that sitll have dependency on NETCONF need to hold off from joining integration/distribution unitl it resolves this issue (rgoulding, 16:46:20) * rovarga asks ecelgp if it affects nitrogen only (rgoulding, 16:46:55) * ecelgp it affects nitrogen only (rgoulding, 16:47:08) * ACTION: ecelgp to push karaf.log or thread dump depending on whetherCPU spikes to 100% (rgoulding, 16:47:26) * if time & interest: infrautils.MoreFutures.logFailure: https://git.opendaylight.org/gerrit/#/c/60207/ (rgoulding, 16:47:34) * LINK: https://git.opendaylight.org/gerrit/#/c/60207/ (rgoulding, 16:47:40) * 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) * rovarga why are you ignoring the Future? That would mean you have no recovery scenarios (rgoulding, 16:49:31) * vorburger claims that most of the DS interactions don’t have recovery scenarios (rgoulding, 16:49:56) * vorburger a warning in the log is a lot better than not getting anything at all (rgoulding, 16:50:11) * rovarga would be much happier with people explicitly adding these (rgoulding, 16:50:30) * 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) * if you are adding in either recovery or succes on top of this logging, then it will degrade performance (rgoulding, 16:51:29) * 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) * 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) * vorburger that assumes people know how to do recovery code (rgoulding, 16:53:10) * vorburger, they haven’t been in 3-4 years (rgoulding, 16:53:19) * skitt says this will hide the real problem and no one will actually know what they are supposed to do (rgoulding, 16:53:40) * 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) * this will at least trigger an eclipse warning (rgoulding, 16:54:38) * skitt this may have people put related operations into a single transactionchain instead of many small transactions (rgoulding, 16:55:07) * vorburger thinks this may be a bit optimistic (rgoulding, 16:55:29) * rovarga this is really useful for single transactions, but less useful for TransactionChain(s) (rgoulding, 16:55:52) * rovarga you can hook an error listener to a TransactionChain for error recovery (rgoulding, 16:56:08) * vorburger many thousands of line of code does not use TransactionChain(s) (rgoulding, 16:56:20) * skitt even if there is deprecation warning or javadoc, they will ignore it and use it because it exists (rgoulding, 16:56:42) * it implies it is "approved" (rgoulding, 16:56:47) * skitt in genius/netvirt you are firing off so many small transactions that it is nearly hard to recover anyway (rgoulding, 16:57:16) * vorburger thinks that it will just make the codelook ugly instead of actually influencing people to do it correctly (rgoulding, 16:57:47) * vorburger is there a middle ground by dismissing the MoreFutures facade (which hides some of this) (rgoulding, 16:58:48) * skitt feels like that this is a waste oftime (rgoulding, 16:59:09) * 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. Action items, by person ----------------------- * vorburger * vorburger to open a bug against releng/builder for wiping sites * **UNASSIGNED** * Sai and Luis to let Atul Gosain know the NETCONF password encryption patch is being reverted to unblock the Carbon-SR1 release * to test the encryption mechanism in master * tcere to +2 netconf encryption patch andemail releng team to merge the patch * ecelgp to push karaf.log or thread dump depending on whetherCPU spikes to 100% People present (lines said) --------------------------- * rgoulding (91) * odl_meetbot (4) * zxiiro (3) * vorburger (1) Generated by `MeetBot`_ 0.1.4