17:03:53 #startmeeting tws 17:03:53 Meeting started Mon Mar 21 17:03:53 2016 UTC. The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html. 17:03:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:03:53 The meeting name has been set to 'tws' 17:03:54 hello 17:04:00 #topic agenda bashing 17:04:12 #link https://wiki.opendaylight.org/view/Tech_Work_Stream:Main#Upcoming_Meeting_Agendas 17:05:01 #info the topics that I've heard for today are: (i) upgrades, (ii) handling integegration/test requirements in boron, (iii) inventory/topology migration 17:07:01 #info 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) 17:07:04 here is a link to the wiki page tom has started around CSS/Blueprint and upgrades 17:07:05 https://wiki.opendaylight.org/view/Upgrades_And_Config_System 17:07:09 #link https://wiki.opendaylight.org/view/Upgrades_And_Config_System 17:07:44 #info 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 17:08:20 #topic handling integration/test requirements in Boron 17:08:21 * zxiiro wouldn't mind going over the maven-sites 17:08:30 #link https://lists.opendaylight.org/pipermail/tsc/2016-March/004761.html mailing list thread 17:11:28 #info colindixon says that jamoluhrsen and the general integration/testing team were disappointed that relatively few project did system test 17:12:39 #info 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 17:16:27 #info this is then conveyed in the getting started guide where we list features, we list experimental features separate from regular features 17:16:56 #info 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 17:17:58 #topic topology/inventory models 17:18:14 #info we had planned to try to move to the new I2RS topology model in Berylilum, that didn't happen 17:18:29 #info if we want to do this in boron, we should start thinking (and really doing) now 17:18:50 #info edwarnicke notes and colindixon agrees that this really needs somebody to get behind it and push with help 17:20:20 #link 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 17:21:33 #Info 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 17:23:17 #info 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 17:24:24 #info colindixon notes that the topoprocessing framework had supposedly done some work to help in migration 17:29:18 +1 edwarnicke - we should discuss with rovarga and jan 17:30:14 #Info 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 17:30:46 #action colindixon and phrobb to find somebody to help convey our concerns to the IETF 17:30:52 #undo 17:30:52 Removing item from minutes: 17:31:03 #action colindixon and phrobb to find somebody to help convey our concerns about model changes to the IETF 17:31:09 #topic upgrades 17:31:30 #link https://wiki.opendaylight.org/view/Upgrades_And_Config_System 17:31:34 rgoulding: thanks! 17:33:04 #link https://www.youtube.com/watch?v=048cdgaqAVk&list=PL8F5jrwEpGAhHowBuM_j1u2TCu8kinmWj&index=27 reccording from the related session from the DDF 17:33:17 #Info this was also the most important issue highlighted by the Advisory Group in terms of things that they want to see in Boron 17:33:41 #Info TomP notes that one of the biggest problems with upgrades has to do with the config subystem and xml config files 17:34:27 #Info 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) 17:35:13 #info 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) 17:37:30 #info 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 17:39:31 #info 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 17:40:47 Blueprint is based upon Spring XML 17:41:12 its heavily used in Karaf apps - mostly SOA stuff — see Apache Camel, Apache CXF 17:41:27 #Info 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 17:41:39 the other DI in heavy use is Declarative Services (DS) 17:41:55 #info TomP notes that the config subystem does seem to be a major point of confusion and pain even fore advanced OpenDaylight users 17:42:23 #info vishnoianil, TomP, colindixon, skitt, shague and others have all lost significant amounts of time to this 17:43:16 #info 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 17:44:16 #info 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 17:44:58 #Info 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 17:46:51 #info 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 17:47:18 #info colindixon notes that he's not sure how much of determinisitc load ordering has survived the config subsytems migration to karaf 17:48:53 Karaf’s Blueprint deployer code for anyone whom wants to see specifically how BP is loaded https://github.com/apache/karaf/tree/karaf-3.0.x/deployer/blueprint 17:50:10 #Info 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 17:51:13 #Info TomP notes that you can use stub services to reintroduce them 17:52:10 #info TomP notes that he's prototyped a version of this for some parts of OpenDaylight, namely the controller 17:52:53 #Info TomP notes that if we allow for parallel ordering when there aren't dependencies, that could speed up loading of OpenDaylight 17:53:38 #info 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 17:54:09 #Info David Karr notes that this might also help controller startup 17:54:42 Your app with enter a Grace Period if a call is made to a proxy without an imple / backing service, once that dependency/service comes up it’ll go to active state 17:55:40 #Info 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 17:56:16 ManagedServiceFactory example https://github.com/jgoodyear/ApacheKarafCookbook/tree/master/chapter2/chapter2-recipe6/msf https://github.com/jgoodyear/ApacheKarafCookbook/blob/master/chapter2/chapter2-recipe6/msf/src/main/resources/OSGI-INF/blueprint/blueprint.xml 17:56:57 #Info TomP also notes there some fixes to issues surrounding ConfigAdmin that make it possible to do transactional changes to config like the config subsystem 17:57:11 #link https://github.com/jgoodyear/ApacheKarafCookbook/blob/master/chapter2/chapter2-recipe6/msf/src/main/resources/OSGI-INF/blueprint/blueprint.xml example from icbts 17:57:32 #link https://github.com/jgoodyear/ApacheKarafCookbook/tree/master/chapter2/chapter2-recipe6/msf example from icbts 17:57:48 JPA / JTA for Karaf 3 https://github.com/jgoodyear/ApacheKarafCookbook/tree/master/chapter7 17:57:59 (Java Persistence/ Java Transaction Manager) 17:58:31 #link https://github.com/jgoodyear/ApacheKarafCookbook/tree/master/chapter7 (Java Persistence/ Java Transaction Manager from icbts) 17:59:45 #info 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 18:01:19 #info 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 18:01:27 #topic example 18:02:19 #info TomP shows how he's migrated some code in OpenDaylight to use blueprint for things like the toaster 18:04:51 #Info TomP shows examles for the toaster and kitchen services 18:05:38 #info colindixon notes that one key advantage of Blueprint is that if you google for issues, you tend to get results 18:07:09 #info TomP notes that he has a few quick extensions to Blueprint that handles common ODL and MD-SAL issues 18:09:19 #info 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 18:10:30 #info 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 18:10:58 #Info TomP said he's asked icbts about when this is likely to hit via Karaf 18:11:52 http://mail-archives.apache.org/mod_mbox/aries-dev/201603.mbox/%3cCAA66TpohxMDGiiUxxyHwE4AixiDzxGjT6KnMyrnpdTVzSGNDtQ@mail.gmail.com%3e 18:12:06 http://mail-archives.apache.org/mod_mbox/aries-dev/201603.mbox/%3cCAA66Tpq045VMdFOddPQ5uM1Zmu7cSeSrD9shAhM7Fy-VVKgxxw@mail.gmail.com%3e 18:12:10 #Info icbts says that that should have been voted on and maybe released 18:13:22 I’ll ask the release manager what’s holding up the release of Aries 18:13:42 icbts: thanks! 18:14:02 #info TomP is looking for community feedback on the idea of movint to Blueprint 18:14:41 colindixon: ok — JB and Christian are working on getting the releases out - they hope to have it in the next week or so — they got clobbered with other pending releases 18:15:09 #Info 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 18:15:35 #info vishnoianil says OVSDB would really like to try to migrate as soon as possible 18:16:47 #info 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 18:18:33 #info 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 18:19:16 First iteration of Blurprint Spring extender https://issues.apache.org/jira/browse/ARIES/fixforversion/12334353/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel 18:19:23 version .2 is in vote 18:19:49 #endmeeting