16:05:26 <colindixon> #startmeeting kernel projects
16:05:26 <odl_meetbot> Meeting started Tue Oct 18 16:05:26 2016 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:05:26 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:05:26 <odl_meetbot> The meeting name has been set to 'kernel_projects'
16:05:34 <colindixon> #topic agenda bashing
16:05:59 <colindixon> #link https://wiki.opendaylight.org/view/Kernel_Projects_Call#Upcoming_Agenda_Topics schedule
16:08:32 <colindixon> #link https://git.opendaylight.org/gerrit/#/c/46534/ it seems like adding put/merge variants was given up on because there's going to be a new way of working with the MD-SAL anyway
16:11:19 <colindixon> #info colindixon asks if there's a really much that will change that it makes sense to hold off
16:11:39 <rgoulding> mixing v1 and v2 is not encouraged
16:12:56 <colindixon> #Info rovarga says that at the current time binding v1 and binding v2 are going to have totally different data brokers, so they won't be mixed
16:13:35 <colindixon> #Info rovarga points out that by going through the binding independent data store in the back a binding v1 and binding v2 application can talk to each other just fine
16:15:03 <colindixon> #info vorburger asks if the plan is to just have each jar be either v1 or v2, but not both, but the overall system will be a mix
16:15:27 <colindixon> #info rovarga notes that for bundles that have a YANG file, they need to generate both v1 and v2 code generated
16:19:08 <colindixon> #info rovarga says that the two binding implementations don't overlap, so techincally, you could use both in an app, it would just suck
16:20:10 <colindixon> #info as we add more bindings, we need to figure out where they're generated, does each jar with a YANG model in it come with binding v1, v2 and maybe scala? that's overhead, but maybe tolerable.
16:20:35 <colindixon> #info rovarga says that it might be better to package individual bidings or generate the bindings as poms import it
16:21:13 <colindixon> #Info rovarga notes that you need both the binding and the model to be imported at the end
16:26:55 <colindixon> #info rovarga draws a diagram showing how we will translate all bindings through the DOM (binding independent) layer to translate from one binding to another
16:28:30 <colindixon> #info vorburger says that at this point, he doesn't have the bandwidth to push this ball and fight for new put/merge variants right now
16:31:39 <colindixon> #topic carbon milestones
16:31:50 <colindixon> #info all kernel projects got M0 milestones in
16:33:08 <colindixon> #info offest 0 (kernel) projects need to get M1 milestones are due Thursday
16:33:19 <colindixon> #topic Eclipse integeration
16:34:00 <colindixon> #info vorburger says that as it stands when he uses Eclipse with our builds bad things happen, espeically if you do both at the same time
16:34:41 <colindixon> #info vorburger says that he's seen CLI builds fail because Eclipse happened to be open
16:35:12 <colindixon> #info vorburger says changing it so that we have two different target directories, one for Eclipse (or other IDEs) and another for the CLI builds would seem to fix this
16:36:41 <colindixon> #info rovarga says that in the past we had problems keeping this working, because (among other things) projects and/or plugins didn't obey the custom target directory
16:37:08 <colindixon> #info rovarga and vorburger say that we have a much, much cleaner build system now and so we might attack this again
16:41:46 <colindixon> #info colindixon adds that his experience was that we had enough issues with developers that don't use eclipse that you are constantly plugging holes to keep things working with Eclipse
16:44:19 <colindixon> #info there is a lot of conversation about how you do maven build plugin stuff in Eclipse using oomph to fix the issues that colindixon was talking about above
16:46:20 <colindixon> #action vorburger and rovarga to talk about how to manage oomph plugins and Eclipse builds over e-mail
16:47:43 <colindixon> #topic YANG 1.1 meeting
16:48:14 <colindixon> #info monday at 9a EST we have the YANG 1.1 meeting
16:48:30 <colindixon> #info a WebEx link will come up
16:49:09 <colindixon> #topic we need projects to address Beryllium-SR4 test failures
16:49:31 <colindixon> #info AAA and bppcep failures are the ones of interest to people here
16:49:44 <colindixon> #action rgoulding to look into AAA
16:50:18 <colindixon> #topic security audit
16:50:41 <colindixon> #info rgoulding asks if we've had anyone do any security audits
16:51:03 <colindixon> #info currently we try to blacklist known-weak cyphers, but we found some projects using non-standard cyphers
16:51:45 <colindixon> #info rovarga says that we really need a crypto best practices page for OpenDaylight
16:51:54 <colindixon> #info rovarga also says that we should have some kind of periodic review
16:52:52 <colindixon> #action rgoulding will start creating that best practices around crypto pages
16:55:03 <colindixon> #info rovarga looks around for crypto stuff that's non-standard; he finds openflowjava has a keystore that's a flat file, and a some kind of TLS configuration that's non-standard
16:56:41 <colindixon> #topic apache mina and sshd-core upgrades
16:57:45 <rovarga> #info mina is bundled with karaf's classpath
16:57:51 <rovarga> #info (mina-ssh)
16:57:59 <colindixon> #info skitt and rovarga say that the patch upgrade these things broke things, it seems like karaf 4.0 will fix it
16:58:08 <rovarga> #info so we have to upgrade karaf to 4.0.x at the very least
16:58:40 <rovarga> #info otherwise things break (caused by the fact a version is on the JVM system classpath not as a bundle)
16:58:52 <colindixon> #action skitt to add rgoulding as a reviewer for the Karaf-4 parent patch when he pushes it
16:59:05 <rovarga> #info we actually are ready to roll in netconf for mina-ssh 1.2.0
16:59:57 <colindixon> #endmeeting