16:07:31 <colindixon> #startmeeting MD-SAL interest call
16:07:31 <odl_meetbot> Meeting started Tue Jul 22 16:07:31 2014 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:07:31 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:07:31 <odl_meetbot> The meeting name has been set to 'md_sal_interest_call'
16:07:43 <colindixon> #topic agenda bashing
16:08:09 <colindixon> #link https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Agenda the agenda in it’s normal place
16:08:29 <colindixon> #topic status updates
16:10:59 <colindixon> #info colindixon is hoping to get DataObject serialization to XML (and hopefully JSON) working this week as well as maybe deserialization
16:11:18 <colindixon> #link https://lists.opendaylight.org/pipermail/yangtools-dev/2014-July/000299.html some more info here
16:12:29 <colindixon> #info the commit() method on transactions is now named submit() and consolidates the way you can check how things succeeded or failed
16:14:46 <colindixon> #topic proposal to change behavior of generated builders
16:14:52 <dbainbri> can't hear
16:15:04 <devinavery> I will restate in a second
16:15:15 * tbachman wonders if there’s a large resistor on the phone lines between slovakia and webex
16:15:16 <colindixon> #link https://bugs.opendaylight.org/show_bug.cgi?id=1097 this is the enhancement bug in question
16:16:28 <devinavery> We would be changing the underlying implementation of the builders to allow null == emptyList
16:17:24 <colindixon> #info the core issue is that right now we allow for both a null list and an empty list as different things
16:18:35 <colindixon> #info the proposal is to stop allowing for lists to be null
16:18:41 <dbainbri> is there any known code that relies on it?
16:20:12 <colindixon> #info this means that some code may currently be using that to differentiate between a not-present list and an empty list
16:20:36 <colindixon> #Info dbainbri asks if there’s any code that this will affect
16:21:25 <colindixon> #info tony responds that the openflowplugin stopped producing the topology because it assumed that non-null lists were not empty
16:23:47 <colindixon> #link https://lists.opendaylight.org/pipermail/controller-dev/2014-July/005811.html this is the mailing list discussion (which is largely in favor of making null and empty list the same thing)
16:29:34 <colindixon> #info devinavery asks “Since we have no real objections, how are we going to go about merging this patch?”
16:31:15 <colindixon> #info colindixon says there are really two issues: (1) do we have to change the version of the generated code when the compiler changes, and (2) can we allow people to stay working on older versions of artifacts within reason?
16:32:02 <colindixon> #info tony says that w.r.t. (1) there’s a “v1” in the package name of generated code which corresponds to the binding interface version and we should probably increment that as part of this, although there’s some concern about how to do minor vs. major versioning there
16:32:02 <dbainbri> there is a propery file plugin that reads in property values from an external file. i wonder if this could be used / leveraged to help set some version information as opposed to having different parent poms?
16:32:47 <colindixon> #info edwarnicke says that w.r.t. (2) we’re almost there because we cut weekly releases of all projects every sunday
16:34:36 <colindixon> #info colindixon says that’s all well and good but we don’t have a mechanical way to allow people to roll back to the last weekly release across the board, the weekly releases border on useless
16:35:00 <Madhu> colindixon: the parent pom doesn't carry any inter project dependancies ... isn't it. it carries only the external dependancy
16:35:25 <Madhu> colindixon: so how will the parent pom update every week will help in parallel to weekly releases ?
16:35:57 <colindixon> Madhu: I don’t know, this isn’t my area of expertise
16:37:07 <Madhu> colindixon: okay. Tony's point is valid there. every weekly release must push a gerrit patch that the projects can decide to revert in case of issues
16:37:26 <edwarnicke> Madhu: Not only does the parent pom not carry interproject dependencies... it can't
16:37:28 <Madhu> but am with edwarnicke here that keeping it optional will cause the CI issues that we faced in Hydrogen
16:37:34 <Madhu> edwarnicke: yep :)
16:37:45 <Madhu> edwarnicke: but we can carry just variables in parent pom
16:37:49 <edwarnicke> Madhu: I am saying there are basically two things:
16:37:51 <Madhu> and the variables can be used
16:37:53 <edwarnicke> 1) Default behavior
16:37:57 <edwarnicke> 2)  Projects choices
16:38:06 <Madhu> edwarnicke: yep. i agree with both
16:38:14 <edwarnicke> I strenously maintain that #1 (default) should be continuous integration.
16:38:15 <Madhu> Default behavior should be in sync
16:38:28 <Madhu> project can choose to roll back for the sake of temporary glitches
16:38:29 <edwarnicke> I also (as you recall) strenuously support project choice in general
16:38:48 <dbainbri> if we are changing behavior isn't that an API change and require a version tick?
16:38:52 <Madhu> we don't want another Hydrogen :)
16:39:00 <Madhu> dbainbri: it must.
16:39:03 <edwarnicke> (which does not mean I won't call folks who go chronically out of sync names in public ;) ... or point out to them when they do have to catch up that they chose that pain ;) )
16:39:14 <colindixon> Madhu: but if you don’t specify versions in your pom file (which you really shouldn’t) then you can roll back and forth between weeklies and continuous by changing your pom file, right?
16:39:23 <dbainbri> and if we version tick, we we not break other projects code?
16:39:44 <edwarnicke> Madhu: And there is one other wrinkle, which is that if a project is out of sync come Sunday for weekly builds, it breaks the weeklies, because they won't tolerate version skew (which is actually a feature ;))
16:39:59 <Madhu> edwarnicke: i love the feature.
16:40:23 <Madhu> dbainbri: yes. version tick is important. and weekly release should sync it up as well
16:40:34 <Madhu> because of the version plugins will bring to the latest and greatest SNAPSHOT
16:41:10 <edwarnicke> Madhu: I am generally a 'fail early, fail often, fail obviously' kind of guy... but I *do* understand also the "I'm in the middle of something and don't want to deal with this for a few days" as well.
16:41:21 <colindixon> #info devinavery tries to push us back to the real discussion: there are two proposals: (i) push the change today and give people the rest of the week to fix it and (ii) give people the warning and then push the change on monday
16:41:24 <rovarga_> so if we are doing isolation, we do need a dashboard which reflects what the current version skew looks like, so that hotspots can be identified and zeroed into
16:41:29 <edwarnicke> Madhu: Actually... the autorelease version skew thing is more clever than that
16:41:41 <colindixon> #info a third proposal from dbainbri is to push it now, but with a version tick
16:42:04 <rovarga_> I don't think we are ready for version tick
16:42:17 <dbainbri> rocarga_: why?
16:42:33 <dbainbri> rovarga_: sorry about the typo?
16:42:35 <rovarga_> because you still need to be able to support v1 regenerating their models
16:42:43 <edwarnicke> If project A is publishing foo-0.1.1-SNAPSHOT, the autorelease converts it to foo-0.1.1-vYYYYMMDD-sha1
16:42:52 <rovarga_> so a version tick means creating a parallel maven plugin plugin
16:43:09 <edwarnicke> If project B is stil depending on foo-0.1.0-SNAPSHOT, its dependency gets ramped to foo-0.1.0-vYYYYMMDD-sha1
16:43:12 <rovarga_> unless I am missing wchih version is being ticked
16:43:13 <edwarnicke> Which will not exist
16:43:19 <edwarnicke> Breaks the autorelease build
16:44:03 <rovarga_> so I take it you want to tick the spec version
16:44:45 <rovarga_> which would be fine, except ticking those versions increases load on yangtools personnel
16:45:59 <rovarga_> so we really do not want to have more than 2 versions supported at any given time
16:49:21 <colindixon> #info a long discussion goes on (see IRC and/or recording) where it seems as though a version tick in the pom.xml file won’t solve the problem because you can end up with different bundle using different versions of the model which are now indistinguishable
16:49:41 <Madhu> rovarga_: edwarnicke i think we can continue discussing on the version tick here ?
16:50:04 <Madhu> rovarga_: edwarnicke am missing the point on version tick (on the POM artifact version) not the yang version
16:50:17 <Madhu> why won't it work ?
16:50:33 <colindixon> #info as a consequence, the plan of record is to merge this change on Monday 7/28 after sending an e-mail to warn people
16:50:57 <colindixon> #topic changes in RESTCONF to support AAA
16:52:10 <colindixon> #info the currently the RESTCONF is hard-wired to the data broker (which doesn’t support AAA)
16:52:40 <colindixon> #info to provide AAA, we need to have a configurable wiring of RESTCONF onto a backing implementation that can support AAA
16:53:59 <colindixon> #info the proposal is to make RESTCONF something that the config subsystem can manage so this can be done
16:54:29 <rovarga_> on that ... can you just provide a proxy data broker?
16:54:39 <rovarga_> and yes, drive it via config
16:54:45 <colindixon> #info edwarnicke asks if there’s anything else that needs to be changed in RESTCONF to make sure that it passes appropriate authentication context as well
16:54:48 <colindixon> #info answer is no
16:54:58 <colindixon> rovarga_: good question
16:56:15 <colindixon> rovarga_: I think that’s the proposal—to implement a databroker proxy that does authentication
16:57:03 <rovarga_> and if restconf is bound to databroker via config, you get predictable lifecycle, so can activate restconf only after all the other apps are up and running
16:57:15 <rovarga_> e.g. "no data available" goes away
16:57:52 <edwarnicke> rovarga_: :)
16:59:40 <colindixon> #endmeeting