#opendaylight-meeting: MD-SAL call

Meeting summary

1. 1. md_sal_call on 5/13/14 (regXboi, 16:10:25)
   2. agenda is to discuss how to support models using different versions of yang? (regXboi, 16:11:03)
   3. https://git.opendaylight.org/gerrit/#/c/6399/ (moizer, 16:14:47)
   4. https://git.opendaylight.org/gerrit/#/c/6399/ (ttkacik, 16:15:00)
   5. https://git.opendaylight.org/gerrit/#/c/6399/ link for gerrit patch that lead to the conversation (regXboi, 16:15:22)
   6. https://bugs.opendaylight.org/show_bug.cgi?id=735 is the bug filed that started this (regXboi, 16:19:35)
   7. question about whether the bug is helium only or backport to hydrogen? (regXboi, 16:21:53)
   8. answer is that it is helium onlyu (regXboi, 16:22:02)
   9. Bug has 3 options (see comment from Mathieu Lemay in above bug) on Pathset 2 (alagalah, 16:22:10)
   10. answer is that it is helium only (regXboi, 16:22:17)
   11. discussion of the various options (regXboi, 16:25:59)
   12. question about the root cause (regXboi, 16:26:29)
   13. statement that the problem is how to evolve the model when it can't be extended (regXboi, 16:27:02)
   14. question about why we need to do something different with auto generated code than in hand written code (regXboi, 16:27:44)
   15. point that model updates are supposed to be backwards compatible per RFC 6022 (regXboi, 16:30:17)
   16. regXboi points out that there isn't a lot of backstory in the bug/comments, and we need that information else it seems opaque (alagalah, 16:33:50)
   17. levelset - in trying to fix defect, required an update of ietf-restconf.yang (regXboi, 16:35:29)
   18. that required update of ietf-yang-types (regXboi, 16:35:46)
   19. now the question is what is the proper way of upgrading ietf-yang-types (or any yang model) in ODL (regXboi, 16:37:09)
   20. and this is important because any project that has a YANG model will need to deal with this issue when they update it (regXboi, 16:38:55)
   21. question if option 3 removes typing and leaving a pure DOM approach (regXboi, 16:46:16)
   22. answer: it very well could (regXboi, 16:46:26)
   23. continued discussion of option 3 and how it relates to binding (regXboi, 16:49:40)
   24. question is whether or not to deprecate java bindings... moves issues from built time to runtime (edwarnicke, 16:49:41)
   25. problem with the current patch is that it will cause explosion in number of dependent classes (regXboi, 16:51:09)
   26. question about changes being kept "backwards-compatible" (regXboi, 16:52:11)
   27. answer is that the system treats changing versions as not backwards compatible but with close on failure (regXboi, 16:52:43)
   28. 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 (regXboi, 16:54:57)
   29. answer it is more how applications access to the APIs and how to handle the backward compatibility from within OSGi (regXboi, 16:55:33)
   30. regXboi had to leave - can't scribe any more (regXboi, 17:00:59)
   31. question: could this be split into two problems: how do you get information about version of things? how do you manage multiple versions? (edwarnicke, 17:01:16)
   32. tentative agreement to split the question and expose the model versions to get unblocked immediately (edwarnicke, 17:03:48)
   33. 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") (kwatsen, 17:04:38)
   34. consider the problem similar to what an NMS would need to do to support devices having different software image versions installed (kwatsen, 17:06:56)

Action items

1. (none)

People present (lines said)

1. regXboi (30)
2. alagalah (14)
3. edwarnicke (11)
4. odl_meetbot (5)
5. kwatsen (3)
6. dbainbri (2)
7. moizer (2)
8. abhijitkumbhare (2)
9. ttkacik (1)
10. raghu67_ (1)