16:09:43 #startmeeting MD-SAL call 16:09:43 Meeting started Tue May 13 16:09:43 2014 UTC. The chair is edwarnicke. Information about MeetBot at http://ci.openstack.org/meetbot.html. 16:09:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:09:43 The meeting name has been set to 'md_sal_call' 16:09:48 #chair alagalah 16:09:48 Current chairs: alagalah edwarnicke 16:09:52 #chair regXboi 16:09:52 Current chairs: alagalah edwarnicke regXboi 16:10:25 #info md_sal_call on 5/13/14 16:11:03 #info agenda is to discuss how to support models using different versions of yang? 16:11:10 did I get that right? 16:12:19 regXboi: I think it might be about the versioning semantics / mechanics 16:12:26 regXboi: (also) 16:13:47 too much echo on webex 16:14:47 https://git.opendaylight.org/gerrit/#/c/6399/ 16:15:00 https://git.opendaylight.org/gerrit/#/c/6399/ 16:15:22 #link https://git.opendaylight.org/gerrit/#/c/6399/ link for gerrit patch that lead to the conversation 16:19:35 #link https://bugs.opendaylight.org/show_bug.cgi?id=735 is the bug filed that started this 16:21:53 #info question about whether the bug is helium only or backport to hydrogen? 16:22:02 #info answer is that it is helium onlyu 16:22:10 #info Bug has 3 options (see comment from Mathieu Lemay in above bug) on Pathset 2 16:22:17 #info answer is that it is helium only 16:23:59 Is this call being recorded? 16:24:04 yes 16:24:10 ok -thx 16:24:16 and we are *trying* to collect minutes here 16:24:31 although I admit to not even getting how I get from the defect link to the solutions 16:24:45 the discussion seems to be missing some pieces 16:25:59 #info discussion of the various options 16:26:29 #info question about the root cause 16:27:02 #info statement that the problem is how to evolve the model when it can't be extended 16:27:44 #info question about why we need to do something different with auto generated code than in hand written code 16:30:17 #info point that model updates are supposed to be backwards compatible per RFC 6022 16:33:50 #info regXboi points out that there isn't a lot of backstory in the bug/comments, and we need that information else it seems opaque 16:33:56 regXboi: +1 16:35:29 #info levelset - in trying to fix defect, required an update of ietf-restconf.yang 16:35:46 #info that required update of ietf-yang-types 16:37:09 #info now the question is what is the proper way of upgrading ietf-yang-types (or any yang model) in ODL 16:37:31 I also have a question... which can be addressed at the approp 16:37:49 riate juncture, but the crux is, we have a YANG model for our project, what does this whole discussion mean to me? 16:38:55 #info and this is important because any project that has a YANG model will need to deal with this issue when they update it 16:39:05 regXboi: you clipped 16:39:21 Ack the info 16:41:49 Ok, I have a Q: Does this mean that if you change the yang-tools, is there any chance that my Yang model will generate different APIs than it did say "yesterday" ? 16:44:23 If we assume Yang Tools is bug free and the Yang to Java Binding specification is stable, the APIs will not change. But that assumption may not always be true 16:45:01 raghu67_: thanks sir! 16:46:16 #info question if option 3 removes typing and leaving a pure DOM approach 16:46:26 #info answer: it very well could 16:49:12 regXboi: edwarnicke I'm not following this, so unable to scribe this part... 16:49:40 #info continued discussion of option 3 and how it relates to binding 16:49:41 #info question is whether or not to deprecate java bindings... moves issues from built time to runtime 16:51:09 #info problem with the current patch is that it will cause explosion in number of dependent classes 16:52:11 #info question about changes being kept "backwards-compatible" 16:52:43 #info answer is that the system treats changing versions as not backwards compatible but with close on failure 16:54:57 #info question that this is isomorphic to "how do you handle revisions to the API" and the proposal is to discard binding and push the problem to runtime 16:55:33 #info answer it is more how applications access to the APIs and how to handle the backward compatibility from within OSGi 16:58:40 -1 short terms & long term approach. 16:58:49 lets do this change once and correct. 17:00:59 #info regXboi had to leave - can't scribe any more 17:01:16 #info question: could this be split into two problems: how do you get information about version of things? how do you manage multiple versions? 17:01:48 dbainbri: Would very much like your thoughts on splitting the question as you have expressed opposition? 17:03:27 my recommendation for the long-term: just keep the most recent bindings in memory and keep up the illusion of still supporting the old versions for legacy clients (what Ed called "adapters") 17:03:48 #info tentative agreement to split the question and expose the model versions to get unblocked immediately 17:04:14 kwatsen: Could you #info your suggestion in? 17:04:38 #info my recommendation for the long-term: just keep the most recent bindings in memory and keep up the illusion of still supporting the old versions for legacy clients (what Ed called "adapters") 17:05:52 edwarnicke: The list being? controller-dev ? discuss ? 17:06:13 alagalah: Those two sound good :) 17:06:20 :) 17:06:56 #info consider the problem similar to what an NMS would need to do to support devices having different software image versions installed 18:15:58 #stopmeeting 18:16:05 #endmeeting