#opendaylight-meeting: discussion of Helium RVs

Meeting summary

1. 1. this is an impromptu, informal, and non-binding discussion of Helium release vehicles (colindixon, 18:06:49)
   2. are Madhu and edwarnicke on the line? (regXboi, 18:07:12)
   3. edwarnicke (edwarnicke, 18:07:24)
   4. rovarga :) (rovarga, 18:07:39)
   5. phrobb (phrobb, 18:07:46)
   6. regXboi (as somebody who actually proposed He RVs :) ) (regXboi, 18:07:56)
   7. https://meetings.opendaylight.org/opendaylight-meeting/2014/tsc/opendaylight-meeting-tsc.2014-07-31-16.59.log.html#l-132 minutes talking about release vehicles (colindixon, 18:08:16)
   8. there was a discussion of RV on 7/31 (regXboi, 18:08:22)
   9. https://meetings.opendaylight.org/opendaylight-meeting/2014/tsc/opendaylight-meeting-tsc.2014-07-31-16.59.log.html#l-132 (regXboi, 18:08:41)
   10. https://meetings.opendaylight.org/opendaylight-meeting/2014/tsc/opendaylight-meeting-tsc.2014-07-31-16.59.log.html (regXboi, 18:09:25)
   11. so the unofficial direction has been to use Karaf with an empty blank slate and load features on the fly (regXboi, 18:10:12)
   
   
2. technical details about a single karaf distribution (colindixon, 18:18:01)
   1. edwarnicke notes that currently integration produces a zip file with all the content to be able to activate *any* feature (colindixon, 18:18:31)
   2. which ones are made active at boot is determined by a single config file in that zip file (colindixon, 18:18:59)
   3. as a consequence, it is *possible* to create a server-side script or page that lets users select features, changes the config file so that those features are made active at boot (but keeps all the jars even for unselected features) (colindixon, 18:21:09)
   4. colindixon wants to have a script which takes (1) a list of features and (2) a zip file for a karaf distribution, then it changes the zip file to cause those features and only those features to be activated at boot. (colindixon, 18:25:46)
   5. that script could then be run by whatever UI you want, e.g., a common web interface that could be both local to reconfigure your downloaded zip and server-hosted to get a zip that has the defaults you’d want (colindixon, 18:26:28)
   
   
3. back to release vehicles (karaf vs. (colindixon, 18:26:43)
   1. cdub wants to go over any of the issues with a pure-karaf release (colindixon, 18:27:05)
   2. collindixon: the script 1) opens the zip, changes the config file (to activate said features), and then 3) re-zips the result - right? (kwatsen, 18:27:35)
   3. cdub points out one is about testing, now we have ~2^f (for f features) combinations rather than 3 (colindixon, 18:27:37)
   4. kwatsen: that was my thinking yes (there are libraries that enable you to edit the contents of the zip in place as well, but that’s pretty deep in the weeds) (colindixon, 18:28:41)
   5. the script could be run again and again too, each time reading in which features are active (none by default), producing a new zip that the script could run on again. That point being is that only the config file changes, the zip file essentially never changes (kwatsen, 18:30:25)
   6. kwatsen that would be my choice, though it could have an option to produce a new zip file as well (why not?) (colindixon, 18:31:35)
   7. edwarnicke says that some of the ~2^f is mitigated because karaf gets things loaded somewhat deterministically, which does away with a whole class of heisenbugs (colindixon, 18:34:46)
   8. the other question about pure karaf is, how will users migrate from the Hydrogen release vehicle that they liked? (colindixon, 18:38:02)
   9. the response is two parts: first, are there any such users? (colindixon, 18:38:14)
   10. second, even if there are, can we produce the Hydrogen release vehicles with the Helium projects and code? (colindixon, 18:38:52)
   11. Madhu returns and says he’s actually OK with a pure-karaf release, but his biggest worry is testing (colindixon, 18:40:01)
   12. his worry is that projects haven’t had enough time to test their project in the karaf distribution (colindixon, 18:40:25)
   13. https://bugs.opendaylight.org/show_bug.cgi?id=1802 (cdub, 18:40:43)
   14. edwarnicke and rovarga argue that this a specific bug, not an example of something wrong with karaf (colindixon, 18:45:10)
   15. Madhu_offline agrees with that, but said that this didn’t show up until karaf (colindixon, 18:45:25)
   16. https://lists.opendaylight.org/pipermail/openflowplugin-dev/2014-September/001967.html (regXboi, 18:47:36)
   17. https://lists.opendaylight.org/pipermail/openflowplugin-dev/2014-September/001967.html karaf specific configuration bundle clarifcation is needed (Madhu, 18:48:02)
   18. colindixon notes that there appears to be no data or evidence to support the fact that pure karaf is *more* bug prone than any alternative (colindixon, 18:48:09)
   19. edwarnicke and regXboi agree there (colindixon, 18:48:18)
   20. cdub notes that karaf *has* turned a non-deterministic bug into a deterministic bug, which we may or may not be able to fix in the time-frame that we have (colindixon, 18:49:02)
   21. Madhu further notes that his worry is that this might befall other projects as well (colindixon, 18:49:18)
   22. https://docs.google.com/spreadsheets/d/1TRYposNDFPaKcySlvwkOXvfR6Anx2EFujlIjoTthhRY/edit#gid=638121282 (this is the link cdub wanted) (colindixon, 19:04:19)
   23. https://wiki.opendaylight.org/view/Karaf:Step_by_Step_Guide this is the documentation to get your karaf feature in (colindixon, 19:06:31)
   24. that was for cdub above (colindixon, 19:06:38)
   25. https://wiki.opendaylight.org/view/Karaf:How_to_create_a_configfile_project_for_Karaf is the one :) (Madhu, 19:08:27)

Action items

1. (none)

People present (lines said)

1. colindixon (41)
2. regXboi (26)
3. cdub (10)
4. phrobb (6)
5. odl_meetbot (6)
6. Madhu (5)
7. dfarrell07 (5)
8. tbachman (4)
9. CASP3R (2)
10. kwatsen (2)
11. rovarga (1)
12. edwarnicke (1)
13. hideyuki (1)