16:02:22 <colindixon> #startmeeting MD-SAL interest call
16:02:22 <odl_meetbot> Meeting started Tue May  5 16:02:22 2015 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
16:02:22 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:22 <odl_meetbot> The meeting name has been set to 'md_sal_interest_call'
16:02:25 <colindixon> #topic agenda bashing
16:02:38 <colindixon> #chair tbachman
16:02:38 <odl_meetbot> Current chairs: colindixon tbachman
16:03:03 <colindixon> #chair rovarga
16:03:03 <odl_meetbot> Current chairs: colindixon rovarga tbachman
16:03:22 <colindixon> icbts: it appears as though we’re waiting for people to drift from the clustering call
16:03:34 <icbts> colindixon: no problem
16:03:40 <icbts> lots of meetings everywhere
16:03:53 <colindixon> #link https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Agenda the agenda in it’s usual place
16:04:00 <icbts> spent my morning listing to Opnfv meetings
16:04:12 <colindixon> icbts: do you know IRC meetbot syntax well?
16:04:19 <icbts> some what
16:04:33 * colindixon is curious if he can wander down and make lunch with his headset, but no keyboard…
16:05:07 <icbts> colindixon: Cool note - Sonatype Nexus 3 is now a custom Karaf based distribution :)
16:07:30 <colindixon> #info the plan is to do a bug scrub first and then cover a few topics carol posted ot the wiki
16:07:56 <colindixon> #topic bug scrub
16:08:45 <colindixon> #info using the same search query as last week
16:12:25 <icbts> Sounds like something to bring Ed in on
16:12:34 <icbts> Config Pusher  was something we worked on togehter
16:15:03 <icbts> We need to look closer at what the wiring constraints were
16:15:04 <colindixon> #link https://lists.opendaylight.org/pipermail/controller-dev/2015-April/009187.html this e-mail has the bug lists we’re looking at
16:18:24 <colindixon> #link https://bugs.opendaylight.org/show_bug.cgi?id=2976 this bug seems have an issue which is happens when you restart the controller
16:19:04 <colindixon> #info Tom Pantelis points out that this means it’s very hard to to upgrades, which is something that he cares about and things the project as a whole should worry about
16:19:43 <colindixon> #info rovarga says that in his mind, getting migratoin to work in code is going to be hard, but instead we need some kind of migration script and an integration test to check it
16:22:01 <icbts> sounds like we need to fix those configs to work better to the current architecture
16:22:10 <colindixon> #info the key issue seems to be that there is a conflict between stored config and initial config and resolving it is painful…
16:24:57 <icbts> Can you link the bug here?
16:25:15 * colindixon point points ^^^^^^
16:25:17 <colindixon> 2976
16:25:25 <icbts> oh, thx
16:29:34 <colindixon> #info icbts talks about how karaf features configs work in general, and the claim is that they work by watching the /etc config files and changing it for features
16:29:55 <icbts> ConfigAdmin + Fileinstall monitors etc folder
16:30:00 <icbts> on change configadmin is updated
16:31:34 <icbts> Separate out configurations? Some stuff in etc working as per normal karaf usage patterns, the rest in other configuration folders that work as per legacy design?
16:32:51 <colindixon> #info icbts points out some more details about how karaf works (see the full logs for some more details)
16:33:49 * colindixon tries to parse and log the discussion
16:34:49 <colindixon> #info Tom Pantelis points out that part of the problem is that we’re conflating wiring with more traditional config, the wiring part being in the config and thus not redone on upgrade is what’s causing the problems, while traditional config seems to have sane solutions
16:36:17 <icbts> hmm… similar to keeping AMQ.xml in Servicemix/Jboss’s karaf. Updates to that xml is basically just over writing the xml file. The AMQ JMS broker is required to stop & restart to take the new config though.
16:37:06 <colindixon> icbts: I think the issue is that we have a few different logical layers of “config”
16:37:16 <icbts> exactly
16:37:20 <colindixon> a developer layer, a packager layer, and a user layer
16:37:23 <icbts> its complex
16:37:28 <colindixon> and we have no way to selectively blow them away
16:37:32 <colindixon> and when we should
16:38:09 <icbts> Karaf has traditionally only had to deal with etc properties files, and some xml - ODL use case is certainly more complex
16:38:47 <colindixon> #info there is some agreement that we have (at least) 3 layers of config: *developer* done when code is built, *packager/system integrator* done when assembling different parts, and *user* done once it’s installed and running
16:40:45 <colindixon> #info the key issue is that we don’t have differnet ways to manage these parts of the config with different lifecyles even though they cleary have different lifecycles
16:41:49 <colindixon> #info for example, when upgrading, you might want to “blow away” the developer and packager config so that it’s reloaded, but you want to keep (or migrate) the user config
16:46:52 <colindixon> #topic allowing for upgrade from Helium to Lithium
16:47:31 <colindixon> #info Tom Panteils, Tony, LuisGomez and others talk about how to do an upgrade from running Helium to running Lithium (via a reboot)
16:48:23 <colindixon> #info Tony asks about upgrading from Karaf 3.0.1 to 3.0.3 and icbts says you stop Karaf and lay down the new files over it and reboot
16:50:44 <colindixon> #info Tony says the specific bug (2976) should be fixable in Lithium pretty easily by RC0
16:52:46 <colindixon> #info for migrating from Helium to Lithium will likely involve setting up an integration test and then ask invididual projects to provide scripts to upgrade the config files as appropriate
16:56:18 <colindixon> #action colindixon to raise a bug about Helium to Lithium migration and schedule time on the TSC (and maybe TWS) discuss this
17:02:08 <colindixon> #action colindixon and LuisGomez to touch base about how to reach out to projects in general about upgrading
17:04:58 <colindixon> #endmeeting