17:03:53 <colindixon> #startmeeting tws
17:03:53 <odl_meetbot> 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 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:53 <odl_meetbot> The meeting name has been set to 'tws'
17:03:54 <colindixon> hello
17:04:00 <colindixon> #topic agenda bashing
17:04:12 <colindixon> #link https://wiki.opendaylight.org/view/Tech_Work_Stream:Main#Upcoming_Meeting_Agendas
17:05:01 <colindixon> #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 <colindixon> #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 <rgoulding> here is a link to the wiki page tom has started around CSS/Blueprint and upgrades
17:07:05 <rgoulding> https://wiki.opendaylight.org/view/Upgrades_And_Config_System
17:07:09 <rgoulding> #link https://wiki.opendaylight.org/view/Upgrades_And_Config_System
17:07:44 <colindixon> #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 <colindixon> #topic handling integration/test requirements in Boron
17:08:21 * zxiiro wouldn't mind going over the maven-sites
17:08:30 <colindixon> #link https://lists.opendaylight.org/pipermail/tsc/2016-March/004761.html mailing list thread
17:11:28 <colindixon> #info colindixon says that jamoluhrsen and the general integration/testing team were disappointed that relatively few project did system test
17:12:39 <colindixon> #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 <colindixon> #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 <colindixon> #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 <colindixon> #topic topology/inventory models
17:18:14 <colindixon> #info we had planned to try to move to the new I2RS topology model in Berylilum, that didn't happen
17:18:29 <colindixon> #info if we want to do this in boron, we should start thinking (and really doing) now
17:18:50 <colindixon> #info edwarnicke notes and colindixon agrees that this really needs somebody to get behind it and push with help
17:20:20 <colindixon> #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 <colindixon> #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 <colindixon> #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 <colindixon> #info colindixon notes that the topoprocessing framework had supposedly done some work to help in migration
17:29:18 <abhijitkumbhare> +1 edwarnicke - we should discuss with rovarga and jan
17:30:14 <colindixon> #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 <colindixon> #action colindixon and phrobb to find somebody to help convey our concerns to the IETF
17:30:52 <colindixon> #undo
17:30:52 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Action object at 0x294c3d0>
17:31:03 <colindixon> #action colindixon and phrobb to find somebody to help convey our concerns about model changes to the IETF
17:31:09 <colindixon> #topic upgrades
17:31:30 <rgoulding> #link https://wiki.opendaylight.org/view/Upgrades_And_Config_System
17:31:34 <colindixon> rgoulding: thanks!
17:33:04 <colindixon> #link https://www.youtube.com/watch?v=048cdgaqAVk&list=PL8F5jrwEpGAhHowBuM_j1u2TCu8kinmWj&index=27 reccording from the related session from the DDF
17:33:17 <colindixon> #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 <colindixon> #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 <colindixon> #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 <colindixon> #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 <colindixon> #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 <colindixon> #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 <icbts> Blueprint is based upon Spring XML
17:41:12 <icbts> its heavily used in Karaf apps - mostly SOA stuff — see Apache Camel, Apache CXF
17:41:27 <colindixon> #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 <icbts> the other DI in heavy use is Declarative Services (DS)
17:41:55 <colindixon> #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 <colindixon> #info vishnoianil, TomP, colindixon, skitt, shague and others have all lost significant amounts of time to this
17:43:16 <colindixon> #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 <colindixon> #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 <colindixon> #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 <colindixon> #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 <colindixon> #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 <icbts> 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 <colindixon> #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 <colindixon> #Info TomP notes that you can use stub services to reintroduce them
17:52:10 <colindixon> #info TomP notes that he's prototyped a version of this for some parts of OpenDaylight, namely the controller
17:52:53 <colindixon> #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 <colindixon> #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 <colindixon> #Info David Karr notes that this might also help controller startup
17:54:42 <icbts> 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 <colindixon> #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 <icbts> 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 <colindixon> #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 <colindixon> #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 <colindixon> #link https://github.com/jgoodyear/ApacheKarafCookbook/tree/master/chapter2/chapter2-recipe6/msf example from icbts
17:57:48 <icbts> JPA / JTA for Karaf 3 https://github.com/jgoodyear/ApacheKarafCookbook/tree/master/chapter7
17:57:59 <icbts> (Java Persistence/ Java Transaction Manager)
17:58:31 <colindixon> #link https://github.com/jgoodyear/ApacheKarafCookbook/tree/master/chapter7 (Java Persistence/ Java Transaction Manager from icbts)
17:59:45 <colindixon> #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 <colindixon> #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 <colindixon> #topic example
18:02:19 <colindixon> #info TomP shows how he's migrated some code in OpenDaylight to use blueprint for things like the toaster
18:04:51 <colindixon> #Info TomP shows examles for the toaster and kitchen services
18:05:38 <colindixon> #info colindixon notes that one key advantage of Blueprint is that if you google for issues, you tend to get results
18:07:09 <colindixon> #info TomP notes that he has a few quick extensions to Blueprint that handles common ODL and MD-SAL issues
18:09:19 <colindixon> #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 <colindixon> #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 <colindixon> #Info TomP said he's asked icbts about when this is likely to hit via Karaf
18:11:52 <icbts> http://mail-archives.apache.org/mod_mbox/aries-dev/201603.mbox/%3cCAA66TpohxMDGiiUxxyHwE4AixiDzxGjT6KnMyrnpdTVzSGNDtQ@mail.gmail.com%3e
18:12:06 <icbts> http://mail-archives.apache.org/mod_mbox/aries-dev/201603.mbox/%3cCAA66Tpq045VMdFOddPQ5uM1Zmu7cSeSrD9shAhM7Fy-VVKgxxw@mail.gmail.com%3e
18:12:10 <colindixon> #Info icbts says that that should have been voted on and maybe released
18:13:22 <icbts> I’ll ask the release manager what’s holding up the release of Aries
18:13:42 <colindixon> icbts: thanks!
18:14:02 <colindixon> #info TomP is looking for community feedback on the idea of movint to Blueprint
18:14:41 <icbts> 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 <colindixon> #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 <colindixon> #info vishnoianil says OVSDB would really like to try to migrate as soon as possible
18:16:47 <colindixon> #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 <colindixon> #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 <icbts> 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 <icbts> version .2 is in vote
18:19:49 <colindixon> #endmeeting