#opendaylight-meeting: tws

Meeting started by colindixon at 17:03:53 UTC (full logs).

Meeting summary

  1. agenda bashing (colindixon, 17:04:00)
    1. https://wiki.opendaylight.org/view/Tech_Work_Stream:Main#Upcoming_Meeting_Agendas (colindixon, 17:04:12)
    2. the topics that I've heard for today are: (i) upgrades, (ii) handling integegration/test requirements in boron, (iii) inventory/topology migration (colindixon, 17:05:01)
    3. colindixon says he thinks we can breifly cover (ii) and (iii) today and punt them to next week for longer conversation, today would then focus on (i) (colindixon, 17:07:01)
    4. https://wiki.opendaylight.org/view/Upgrades_And_Config_System (rgoulding, 17:07:05)
    5. https://wiki.opendaylight.org/view/Upgrades_And_Config_System (rgoulding, 17:07:09)
    6. colindixon asks if we have other topics we'd like to cover, e.g., zxiiro covering maven sites and javadoc which we now have support (colindixon, 17:07:44)

  2. handling integration/test requirements in Boron (colindixon, 17:08:20)
    1. https://lists.opendaylight.org/pipermail/tsc/2016-March/004761.html mailing list thread (colindixon, 17:08:30)
    2. colindixon says that jamoluhrsen and the general integration/testing team were disappointed that relatively few project did system test (colindixon, 17:11:28)
    3. colindixon says that the proposal was to add a mild disincentive to avoid meeting your system and testing requirements, in this case flagging those feautres as experimental (colindixon, 17:12:39)
    4. this is then conveyed in the getting started guide where we list features, we list experimental features separate from regular features (colindixon, 17:16:27)
    5. edwarnicke says that there is some worry about having mega features with one test being fine, while lots of little features would be worse even though it's actually better (colindixon, 17:16:56)

  3. topology/inventory models (colindixon, 17:17:58)
    1. we had planned to try to move to the new I2RS topology model in Berylilum, that didn't happen (colindixon, 17:18:14)
    2. if we want to do this in boron, we should start thinking (and really doing) now (colindixon, 17:18:29)
    3. edwarnicke notes and colindixon agrees that this really needs somebody to get behind it and push with help (colindixon, 17:18:50)
    4. https://meetings.opendaylight.org/opendaylight-meeting/2015/tws/opendaylight-meeting-tws.2015-09-14-17.02.html meetin minutes from the last time we covered this (colindixon, 17:20:20)
    5. colindixon notes that we currently have three models: inventory that we want to escape from, an expired IETF topology model that everyone but OpenFlow uses, a new I2RS IETF topology which might actually be approved that nearly noone in ODL uses (colindixon, 17:21:33)
    6. vishnoianil points out that there seems to be relatively little value in moving to a yet-to-be-finalized model over an already-expired model (colindixon, 17:23:17)
    7. colindixon notes that the topoprocessing framework had supposedly done some work to help in migration (colindixon, 17:24:24)
    8. abhijitkumbhare asks if we can eliminate the option of using the I2RS model, colindixon says maybe, but probably that's up to the people doing the work (colindixon, 17:30:14)
    9. ACTION: colindixon and phrobb to find somebody to help convey our concerns about model changes to the IETF (colindixon, 17:31:03)

  4. upgrades (colindixon, 17:31:09)
    1. https://wiki.opendaylight.org/view/Upgrades_And_Config_System (rgoulding, 17:31:30)
    2. https://www.youtube.com/watch?v=048cdgaqAVk&list=PL8F5jrwEpGAhHowBuM_j1u2TCu8kinmWj&index=27 reccording from the related session from the DDF (colindixon, 17:33:04)
    3. this was also the most important issue highlighted by the Advisory Group in terms of things that they want to see in Boron (colindixon, 17:33:17)
    4. TomP notes that one of the biggest problems with upgrades has to do with the config subystem and xml config files (colindixon, 17:33:41)
    5. TomP notes that those files combine both code wiring issues (e.g., your dependencies) and user config (e.g., knobs like the openflow port number to listen on) (colindixon, 17:34:27)
    6. this means that upgrading OpenDaylight is likely to want to change wiring, but doing so requires modifiying a file that might also contain user config (which you'd like to avoid blowing away) (colindixon, 17:35:13)
    7. this is further complicated by the fact that config files are all the combined together into a single, big xml config file for all of the config subsystem which makes doing changes harder (colindixon, 17:37:30)
    8. TomP says that he's prototyped the idea of using two config files in the config subsystem one for user config and one for wiriing in the toaster as Tony and Robert suggested, but it was hard and doesn't fix the fact that there's one big config file (colindixon, 17:39:31)
    9. TomP points out there are alternatives to using the config subsystem: (i) ConfigAdmin files, which lose the richness and validation of YANG, but is commonly used for user config, (ii) Blueprint which focuses more on code wiring (colindixon, 17:41:27)
    10. TomP notes that the config subystem does seem to be a major point of confusion and pain even fore advanced OpenDaylight users (colindixon, 17:41:55)
    11. vishnoianil, TomP, colindixon, skitt, shague and others have all lost significant amounts of time to this (colindixon, 17:42:23)
    12. for what it's worth rovarga and others have said that they never intended for people to directly consume the config subsystem, but had envisoned tools to make it easier to use, those tools however haven't come to fruition (colindixon, 17:43:16)
    13. david karr and icbts point out that Blueprint is based on Spring DM and is used hevily in Karaf apps, e.g., Apache Camel and Apache CXF (colindixon, 17:44:16)
    14. TomP says that that there are some things that the config subsystem was designed to do that Blueprint doesn't do that we might want to discuss and/or fix (colindixon, 17:44:58)
    15. the config subsystem (at least used to) provide deterministic ordering of bundles, Blueprint does not provide deterministic ordering, it only orders you baesd on your service dependencies (colindixon, 17:46:51)
    16. colindixon notes that he's not sure how much of determinisitc load ordering has survived the config subsytems migration to karaf (colindixon, 17:47:18)
    17. TomP notes that service dependencies don't always exist because of how we use the MD-SAL to share services that means that you might not have an explicity service dependency (colindixon, 17:50:10)
    18. TomP notes that you can use stub services to reintroduce them (colindixon, 17:51:13)
    19. TomP notes that he's prototyped a version of this for some parts of OpenDaylight, namely the controller (colindixon, 17:52:10)
    20. TomP notes that if we allow for parallel ordering when there aren't dependencies, that could speed up loading of OpenDaylight (colindixon, 17:52:53)
    21. TomP says that there are other nice things like service proxy which creates a local proxy for services you load, that way you can change the implementation transparently later (colindixon, 17:53:38)
    22. David Karr notes that this might also help controller startup (colindixon, 17:54:09)
    23. TomP notes that the config subsystem also does some nice things with pausing and relaunching a variety of bundles when the wiring changes, TomP says he's prototyped doing the same thing using Blueprint (colindixon, 17:55:40)
    24. TomP also notes there some fixes to issues surrounding ConfigAdmin that make it possible to do transactional changes to config like the config subsystem (colindixon, 17:56:57)
    25. https://github.com/jgoodyear/ApacheKarafCookbook/blob/master/chapter2/chapter2-recipe6/msf/src/main/resources/OSGI-INF/blueprint/blueprint.xml example from icbts (colindixon, 17:57:11)
    26. https://github.com/jgoodyear/ApacheKarafCookbook/tree/master/chapter2/chapter2-recipe6/msf example from icbts (colindixon, 17:57:32)
    27. https://github.com/jgoodyear/ApacheKarafCookbook/tree/master/chapter7 (Java Persistence/ Java Transaction Manager from icbts) (colindixon, 17:58:31)
    28. the only remaining thing that's missing from blueprint is that it's key/value-based while the config subystem uses richer YANG-modeled data for user config (colindixon, 17:59:45)
    29. TomP says that if you really want YANG modeled data, you could combine the config subsystem and/or MD-SAL data store with Blueprint and use one for validation and the other for actually loading the config (colindixon, 18:01:19)

  5. example (colindixon, 18:01:27)
    1. TomP shows how he's migrated some code in OpenDaylight to use blueprint for things like the toaster (colindixon, 18:02:19)
    2. TomP shows examles for the toaster and kitchen services (colindixon, 18:04:51)
    3. colindixon notes that one key advantage of Blueprint is that if you google for issues, you tend to get results (colindixon, 18:05:38)
    4. TomP notes that he has a few quick extensions to Blueprint that handles common ODL and MD-SAL issues (colindixon, 18:07:09)
    5. TomP notes that right now he's looking at allowing us to move from config subsystem to blueprint, but having both run in the same Karaf container might be hard (colindixon, 18:09:19)
    6. TomP notes that there's a bug in the service proxy in that it doesn't handles covariant intefaces, the bug is now fixed and will come in the next release of the Aries service proxy, but we're not sure when that will actually be released (colindixon, 18:10:30)
    7. TomP said he's asked icbts about when this is likely to hit via Karaf (colindixon, 18:10:58)
    8. http://mail-archives.apache.org/mod_mbox/aries-dev/201603.mbox/%3cCAA66TpohxMDGiiUxxyHwE4AixiDzxGjT6KnMyrnpdTVzSGNDtQ@mail.gmail.com%3e (icbts, 18:11:52)
    9. http://mail-archives.apache.org/mod_mbox/aries-dev/201603.mbox/%3cCAA66Tpq045VMdFOddPQ5uM1Zmu7cSeSrD9shAhM7Fy-VVKgxxw@mail.gmail.com%3e (icbts, 18:12:06)
    10. icbts says that that should have been voted on and maybe released (colindixon, 18:12:10)
    11. TomP is looking for community feedback on the idea of movint to Blueprint (colindixon, 18:14:02)
    12. in his mind this is three-fold: (i) help upgrades, (ii) help usability, (iii) increase number of resources available online, (iv) possibly allow us to remove a lot of code we currently have to maintain (colindixon, 18:15:09)
    13. vishnoianil says OVSDB would really like to try to migrate as soon as possible (colindixon, 18:15:35)
    14. skitt says that this looks really cool, and that you can find people that know Spring and even that know Blueprint very easily, while finding people that know config subsytem don't exist (colindixon, 18:16:47)
    15. TomP asks about unit testing stuff, icbts says that this is there and it's in pax-exam, there are examles and Apache Camel and CXF (colindixon, 18:18:33)


Meeting ended at 18:19:49 UTC (full logs).

Action items

  1. colindixon and phrobb to find somebody to help convey our concerns about model changes to the IETF


Action items, by person

  1. colindixon
    1. colindixon and phrobb to find somebody to help convey our concerns about model changes to the IETF


People present (lines said)

  1. colindixon (71)
  2. icbts (14)
  3. rgoulding (4)
  4. odl_meetbot (4)
  5. abhijitkumbhare (1)
  6. zxiiro (1)


Generated by MeetBot 0.1.4.