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