#opendaylight-meeting: tsc

Meeting started by colindixon at 17:00:48 UTC (full logs).

Meeting summary

  1. roll call and agenda bashing (colindixon, 17:00:54)
    1. dlenrow (dlenrow, 17:00:56)
    2. colindixon (colindixon, 17:01:05)
    3. jmedved (jmedved, 17:01:15)
    4. https://wiki.opendaylight.org/index.php?title=TSC:Main&oldid=37793#Agenda the agenda in it's usual place (colindixon, 17:01:31)
    5. https://meetings.opendaylight.org/opendaylight-meeting/2015/tsc/opendaylight-meeting-tsc.2015-10-15-17.02.html last week's meeting minutes (colindixon, 17:01:40)
    6. mohnish anumala (mohnish, 17:01:45)
    7. ACTION: colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR3) https://bugs.opendaylight.org/show_bug.cgi?id=3160 (colindixon, 17:01:58)
    8. ACTION: ttcacik and zxiiro to work on getting feature-level code coverage numbers (colindixon, 17:02:27)
    9. ACTION: colindixon to figure out where we lost action items, e.g., feature-level code coverage and make sure we didn't lose any others (colindixon, 17:02:31)
    10. (edwarnicke, 17:02:32)
    11. edwarnicke (edwarnicke, 17:02:35)
    12. Daniel Farrell (dfarrell07, 17:03:39)
    13. LuisGomez (LuisGomez, 17:04:48)

  2. mailing list votes and discussions (colindixon, 17:06:13)
    1. https://lists.opendaylight.org/pipermail/tsc/2015-October/004026.html platinum designate bylaw waiver discussion (colindixon, 17:06:39)
    2. https://lists.opendaylight.org/pipermail/tsc/2015-October/004021.html requirements to remain in a release w.r.t. autorelease (colindixon, 17:06:59)
    3. https://lists.opendaylight.org/pipermail/tsc/2015-October/004032.html should we meet next week despite OpenStack Tokyo next week? (colindixon, 17:07:40)
    4. Chris Price (ChrisPriceAB, 17:08:03)
    5. AGREED: there will be no TSC meeting next week due to OpenStack in Tokyo (colindixon, 17:10:11)

  3. events (colindixon, 17:10:33)
    1. https://www.opendaylight.org/global-events events in the usual place (colindixon, 17:10:58)
    2. https://aws.passkey.com/g/43882140 register for the hackfest (colindixon, 17:11:44)

  4. beryllium (colindixon, 17:12:15)
    1. we have one offset 0 project with no M4 (odlparent) (colindixon, 17:12:32)
    2. we have 10 projects missing for M3, anipbu is contacting them (colindixon, 17:12:52)
    3. we have made a lot of project on autorelase, but we still have two projects which can't be added back into autorelease: NIC and VTN due to dependencies on AD-AL (colindixon, 17:13:39)
    4. currently integration is failing to build because of dependencies on features that no longer exist, there are mailing list threads working on solving that (colindixon, 17:14:18)
    5. benchmarks from coretutorials are going to be created in controller to provide the tests for integration (colindixon, 17:15:20)
    6. LuisGomez says they really need that by M4 (colindixon, 17:15:32)
    7. ACTION: jmedved to talk to ttkacik about how to get the benchmarks into controller by offset 2 M4 (colindixon, 17:15:48)
    8. https://wiki.opendaylight.org/view/Weather#Current_Weather_Report current weather report, anipbu says nothing that needs to come up here (colindixon, 17:16:39)
    9. ACTION: anipbu will open a bug against controller to move the benchmark tools there by M4 offset 2 (colindixon, 17:17:06)
    10. https://wiki.opendaylight.org/view/Weather#Implementation_of_RFC6020_structural_container_lifecycle rovarga says that the patches fro BUG 2399 are coming in and projects should test if they can, they've tested integration tests without issues (colindixon, 17:18:30)
    11. ACTION: rovarga to add BUG 2399 to the weather page for the the structural issue (colindixon, 17:18:52)

  5. stable/lithium (colindixon, 17:19:24)
    1. autorelease is currently breaking while trying to build AAA, there's an e-mail thread trying to diagnose it now (colindixon, 17:19:45)

  6. autorelease (colindixon, 17:22:11)
    1. https://meetings.opendaylight.org/opendaylight-meeting/2015/tsc/opendaylight-meeting-tsc.2015-06-18-17.00.log.html#l-159 Java 8 #agreed (dfarrell07, 17:23:14)
    2. zxiiro says that autorelease for beryllum is making it to integration consistently which is expected until M4 when VTN can drop it's dependecies on the AD-SAL (colindixon, 17:24:52)
    3. rovarga asks how we're doing on moving to JDK8? (colindixon, 17:25:28)
    4. zxiiro suggests that we just JDK8 tests out to projects (colindixon, 17:28:17)
    5. ACTION: alagalah to provide instructions on how to switch from Java 7 to Java 8 and back to test if your project works with Java 8 (colindixon, 17:28:42)
    6. ACTION: anipbu to add a readout on whether you build with Java 8 and wehther you have jdk8 verify, etc. jobs to the M4 readout and note the if you don't by RC time, you will be dropped (colindixon, 17:30:09)
    7. ACTION: zxiiro to create a beryllium-jdk8 autorelease job (replacing the lithium-jdk8 release job) (colindixon, 17:31:27)

  7. system integration & test (colindixon, 17:32:00)
    1. it's been two weeks since the termination review was posted (colindixon, 17:32:35)
    2. https://wiki.opendaylight.org/view/Archive_Proposals/Integration (jamoluhrsen, 17:32:51)
    3. https://lists.opendaylight.org/pipermail/tsc/2015-October/003966.html Integration (pre-split) project termination request email (dfarrell07, 17:33:11)
    4. system tests are passing, but when people are loading lots of features locally, lots of weird things are happeneing (colindixon, 17:33:33)
    5. for example, when jamoluhrsen loads compatible-with-all his controller goes out to lunch for an hour and seems to eventually come up, but with some omenous log messages (colindixon, 17:34:56)
    6. LuisGomez says that even with only 2-3 features that used to work before, Karaf will hang and there are memory issues that weren't there befomre (colindixon, 17:35:29)
    7. rovarga would like to see a memory dump when/if there's an OutOfMemory issue (colindixon, 17:35:48)
    8. rovarga suggests for karaf hangs, using Yourkit to see where it's hung might help (colindixon, 17:36:29)

  8. infastructure (colindixon, 17:36:39)
    1. tykeal- is working slave images that have been having issues (colindixon, 17:37:07)
    2. alagalah asks about ubuntu images in the sandbox, tykeal- says he's stuck because they can install docker in vagrant, but when they snapshot it, it won't come back up with networking because docker doesn't come up well (colindixon, 17:38:10)
    3. tykeal- notes that this is just an issue on how docker installs with an unattendend install on Ubuntu, it works with an attended install, and it works on RHEL (colindixon, 17:38:56)

  9. dealing with upstream/downstream breakages (colindixon, 17:40:14)
    1. alagalah says that, more tactically, he was unable to write any code for 1.5-2 weeks, should we extend the release to the back end (colindixon, 17:43:16)
    2. ebrjohn (Brady) says we desperately need to be able to roll back in an easlier way, instead in his experience as a later offset proejct it's nearly impossible to roll back and make progress (colindixon, 17:45:11)
    3. ebrjohn and abhijitkumbhare suggest doing more frequent mini-releases (colindixon, 17:46:46)
    4. anipbu asks would it be enough to have a relase per milestone, ebrjohn says it's a step forward, but wouldn't fix things entirely (colindixon, 17:49:39)
    5. edwarnicke says if we could get autorelease to run consistently and then we could have tools to roll forward and backward through time with consistent versions across all projects (colindixon, 17:50:24)
    6. https://lists.opendaylight.org/pipermail/release/2015-October/004111.html RPenno's comments on the issue (colindixon, 17:52:38)
    7. edwarnicke says the productive convesation here is to look at how to fix this issue tactically in the short term, e.g., until we get rollback and CR working, which is real work and won't happen immediately (colindixon, 17:54:59)
    8. ebrjohn agrees and says "sometimes shit happens" and what we really need is ways to fix it later (colindixon, 17:55:27)
    9. focus on how to fix shit faster when it happens, reduce the probability of shit happening (edwarnicke, 17:55:53)
    10. rovarga says what offset 0 projects could really use a CSIT red/green test to figure out what is breaking things or not (colindixon, 17:56:21)
    11. https://git.opendaylight.org/gerrit/17030 shows the way we can see how CSIT reacts to a single patchset (rovarga, 17:58:21)
    12. integration is working on trying to figure out how to avoid having tests that are failing so that it's easlier to tell whether things are breaking because they always break or because of something new (colindixon, 17:58:29)
    13. LuisGomez notes that that CSIT doesn't catch everything as many projects don't have very high coverage (colindixon, 18:00:47)
    14. colindixon also notes that CSIT without full build, e.g., autorelease, will miss a whoe other category of issues (colindixon, 18:01:03)
    15. abhijitkumbhare says that another suggestion is that sometimes offset 0 and offset 1 projects should consider reverting patches when "shit happens" (colindixon, 18:02:00)
    16. edwarnicke asks when we should revert and how to deal with remediation (colindixon, 18:03:23)
    17. mohnish says that there may be times where this level nuance (e.g., we need to have both projects engaged and a real dialog to decide if we should revert) isn't needed, e.g., when everyone is having issues (colindixon, 18:05:13)
    18. edwarnicke says there was an example where an upstream project took heisenbugs and made them predictable, that broke downstream people and if they were allowed force upstream projects to never fix it, it woudl have caused real problems (colindixon, 18:06:43)
    19. phrobb suggests a timeline way to deal with when you roll patches back forward (colindixon, 18:06:55)
    20. rovarga says that we need to look at how we analyze breakages, i.e., he says there are 12-15 offset 0 developers, and there are 50ish downstream projects, so requiring every breakage be analyzed by offest 0 people won't scale (colindixon, 18:09:11)
    21. rovarga calls for bettter error reporting, e.g., with logs, and preliminary analysis (colindixon, 18:09:49)
    22. ChrisPriceAB says that there will always be corner case, and we can talk about them and they may or may not help the general case (colindixon, 18:12:40)
    23. ChrisPriceAB says he like to a see a cuture over process here (colindixon, 18:12:50)
    24. edwarnicke suggests that at the very least we need to have instructions to reproduce the bug for it to be taken seriously (colindixon, 18:13:23)
    25. edwarnicke says that absolutely, if the world is broken, revert the patch quickly (colindixon, 18:14:10)
    26. edwarnicke also says that if the patch turns up bugs, and peopel don't engage to fix them downstream, then we shouldn't hold back because they don't engage (colindixon, 18:14:56)
    27. rovarga says that if the world breaks, he's wllling to try to revert as long as there's a time limit on how long the patch stays reverted (colindixon, 18:17:08)
    28. two weeks is suggested, but others say maybe that should be shorter or longer depending on teh bug and projects involved (colindixon, 18:17:32)
    29. a good trade-off is need for time -- two weeks is probably the most tolerable without affecting upstream schedule (rovarga, 18:18:34)
    30. ACTION: rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare will try to draft a paragraph around the best practices including this discussion and feedback (to be gotten) from PTLS (colindixon, 18:22:57)
    31. ebrjohn asks what about technical solutions again (colindixon, 18:23:32)
    32. ebrjohn asks if there was a way to take all the yang files in ODL and do some sanity check for offset 0, really yangtools (colindixon, 18:24:05)
    33. rovarga says in boron, the idea woudl be to have system test for yangtools that pulls in as many models as they can including both ODL yang files as well as from outside (colindixon, 18:24:48)
    34. ACTION: rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare should also feel free to provide feedback around tools and technical solutions to help with upstream/downtream breakages (colindixon, 18:25:40)

  10. delaying the beryllium release (colindixon, 18:26:28)
    1. https://lists.opendaylight.org/pipermail/tsc/2015-October/003999.html (colindixon, 18:26:59)
    2. colindixon and vishnoianil ask what are the consequences going to be if we *don't* grant the extension (colindixon, 18:29:54)
    3. alagalah says in his case, he thinks there will be real consequences, vina_ermagan and ebrjohn all say yes (colindixon, 18:30:35)
    4. ChrisPriceAB says that the B release of OPNFV is shipping on Feburary 2nd regardless, ODL ships on February 5th (colindixon, 18:34:24)
    5. rovarga asks do we have other downstream projects? if so we need a fast way to poll them? (colindixon, 18:35:23)
    6. phrobb_ says that we could also drop an RC (actually two) and keep the release date (colindixon, 18:37:08)
    7. https://wiki.opendaylight.org/view/Simultaneous_Release:Beryllium_Release_Plan#Schedule the schedule for people's use (colindixon, 18:37:29)
    8. abhijitkumbhare asks if 2 weeks will be enough, will we have another breakage and have to delay again (colindixon, 18:38:55)
    9. VOTE: Voted on "shall we delay the Beryllium release and it's relevant milestones by 2 weeks, -1 no, 0 not sure or need more information, +1 yest?" Results are, 0: 5, +1: 2 (colindixon, 18:41:10)
    10. ACTION: phrobb_ to coordinate getting input from PTLs, OPNFV, ODL AG, and Marketing Group, by tomorrow ideally and Monday at the latest (colindixon, 18:44:01)
    11. edwarnicke and jmedved prevote for extending by two weeks unless they actively retract it (colindixon, 18:45:01)
    12. ghall asks if this extends the window of change for the core and the associated risks, colindixon says that API freeze has already happened and that the current plan woudl extend offest 0 M5 (colindixon, 18:47:39)
    13. ghall is worried that most major breakages haven't been API changes, but have been changes in the implementation of the API (colindixon, 18:48:05)
    14. rovarga says that his plan (speaking for YANG tools) is not to bring anything more in because of the extension (colindixon, 18:48:28)
    15. ghall says that publicly slipping our release is bad for business, like abhijitkumbhare he worries about a second slippage and would like to see actions take to make sure we don't slip again if we allow it slip in the first place (colindixon, 18:50:57)

  11. OVSDB scope revision (colindixon, 18:51:02)
    1. https://lists.opendaylight.org/pipermail/tsc/2015-October/004017.html the OVSDB project is asking to change their scope to include the network virtualization part of the project (colindixon, 18:52:14)
    2. from above, vina_ermagan says that lispflowmapping will not be able to hit M4 unles they get a 1 week delay regardless of what the TSC says (colindixon, 18:53:53)
    3. afredette and dfarrell07 note that this is more of aligning the "official" scope on the wiki with the well-understood scope of the project in code and in the community (colindixon, 18:55:18)
    4. edwarnicke asks if they've consulted their downstream projects (colindixon, 18:55:46)
    5. afredette says no, but alagalah points out he saw it, is a downstream consumer, and is fine with it (colindixon, 18:56:21)
    6. colindixon, Well.... I'm ok with the scope change in principal but was clear I would prefer we address the split since I consume OVSDB SB, but not NetVirt, so it makes sense to me two projects, OVSDB SB Offset1, NetVirt Offset 2... it was just a opinion but please reflect what I said :) (alagalah, 18:58:14)
    7. rovarga says the bgpcep has addressed similar issues, he also thinks that splitting instead of revising the scope woudl potentially avoid a cycle between OVSDB and SFC (colindixon, 18:58:50)
    8. mohnish agrees with afredette and dfarrell07 that this is more about aliigning a phrase on the wiki with reality (colindixon, 18:59:34)
    9. afredette says he thinks it does make sense to split the project, he just doesn't think Beryliium is the right time, he just wants to make sure the description matches reality (colindixon, 19:01:48)
    10. rovarga and abhijitkumbhare say that maybe the right idea is to change the scope and then split in Boron (colindixon, 19:02:37)
    11. rovarga asks if the scope change could come with a plan to split in the future (colindixon, 19:02:56)
    12. https://wiki.opendaylight.org/view/Project_Proposals:OVSDB_NetVirt (mohnish, 19:05:28)
    13. https://wiki.opendaylight.org/view/Project_Proposals:OVSDB_NetVirt (rovarga, 19:05:50)
    14. insufficient information (edwarnicke, 19:07:31)
    15. insufficient information (jmedved, 19:07:48)
    16. +1 (ChrisPriceAB, 19:08:35)
    17. VOTE: Voted on "shall the TSC allow for OVSDB scope to include network virtualization assuming they provide a plan to split in Boron?" Results are, 0: 2, +1: 5 (colindixon, 19:08:51)
    18. with eric's verbal +1 (in place of Uri) that does carry (colindixon, 19:09:09)
    19. edwarnicke asks when he can expect a proposal for the split, afredette says early in Boron (colindixon, 19:10:00)
    20. rovarga asks for a propoosal by the tiem Beryllium ships (colindixon, 19:10:19)
    21. afredette asks for a few weeks after it ships (colindixon, 19:10:49)

  12. cookies (colindixon, 19:13:55)


Meeting ended at 19:13:59 UTC (full logs).

Action items

  1. colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR3) https://bugs.opendaylight.org/show_bug.cgi?id=3160
  2. ttcacik and zxiiro to work on getting feature-level code coverage numbers
  3. colindixon to figure out where we lost action items, e.g., feature-level code coverage and make sure we didn't lose any others
  4. jmedved to talk to ttkacik about how to get the benchmarks into controller by offset 2 M4
  5. anipbu will open a bug against controller to move the benchmark tools there by M4 offset 2
  6. rovarga to add BUG 2399 to the weather page for the the structural issue
  7. alagalah to provide instructions on how to switch from Java 7 to Java 8 and back to test if your project works with Java 8
  8. anipbu to add a readout on whether you build with Java 8 and wehther you have jdk8 verify, etc. jobs to the M4 readout and note the if you don't by RC time, you will be dropped
  9. zxiiro to create a beryllium-jdk8 autorelease job (replacing the lithium-jdk8 release job)
  10. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare will try to draft a paragraph around the best practices including this discussion and feedback (to be gotten) from PTLS
  11. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare should also feel free to provide feedback around tools and technical solutions to help with upstream/downtream breakages
  12. phrobb_ to coordinate getting input from PTLs, OPNFV, ODL AG, and Marketing Group, by tomorrow ideally and Monday at the latest


Action items, by person

  1. abhijitkumbhare
    1. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare will try to draft a paragraph around the best practices including this discussion and feedback (to be gotten) from PTLS
    2. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare should also feel free to provide feedback around tools and technical solutions to help with upstream/downtream breakages
  2. alagalah
    1. alagalah to provide instructions on how to switch from Java 7 to Java 8 and back to test if your project works with Java 8
    2. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare will try to draft a paragraph around the best practices including this discussion and feedback (to be gotten) from PTLS
    3. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare should also feel free to provide feedback around tools and technical solutions to help with upstream/downtream breakages
  3. anipbu
    1. anipbu will open a bug against controller to move the benchmark tools there by M4 offset 2
    2. anipbu to add a readout on whether you build with Java 8 and wehther you have jdk8 verify, etc. jobs to the M4 readout and note the if you don't by RC time, you will be dropped
  4. colindixon
    1. colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR3) https://bugs.opendaylight.org/show_bug.cgi?id=3160
    2. colindixon to figure out where we lost action items, e.g., feature-level code coverage and make sure we didn't lose any others
  5. ebrjohn
    1. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare will try to draft a paragraph around the best practices including this discussion and feedback (to be gotten) from PTLS
    2. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare should also feel free to provide feedback around tools and technical solutions to help with upstream/downtream breakages
  6. jmedved
    1. jmedved to talk to ttkacik about how to get the benchmarks into controller by offset 2 M4
  7. mohnish
    1. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare will try to draft a paragraph around the best practices including this discussion and feedback (to be gotten) from PTLS
    2. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare should also feel free to provide feedback around tools and technical solutions to help with upstream/downtream breakages
  8. phrobb_
    1. phrobb_ to coordinate getting input from PTLs, OPNFV, ODL AG, and Marketing Group, by tomorrow ideally and Monday at the latest
  9. rovarga
    1. rovarga to add BUG 2399 to the weather page for the the structural issue
    2. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare will try to draft a paragraph around the best practices including this discussion and feedback (to be gotten) from PTLS
    3. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare should also feel free to provide feedback around tools and technical solutions to help with upstream/downtream breakages
  10. RPenno
    1. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare will try to draft a paragraph around the best practices including this discussion and feedback (to be gotten) from PTLS
    2. rovarga, alagalah, mohnish, ttkacik, vishnoianil, ebrjohn, RPenno, abhijitkumbhare should also feel free to provide feedback around tools and technical solutions to help with upstream/downtream breakages
  11. zxiiro
    1. ttcacik and zxiiro to work on getting feature-level code coverage numbers
    2. zxiiro to create a beryllium-jdk8 autorelease job (replacing the lithium-jdk8 release job)


People present (lines said)

  1. colindixon (140)
  2. edwarnicke (30)
  3. ChrisPriceAB (20)
  4. alagalah (19)
  5. odl_meetbot (18)
  6. ebrjohn (17)
  7. rovarga (13)
  8. vina_ermagan (9)
  9. dfarrell07 (8)
  10. abhijitkumbhare (7)
  11. dneary (6)
  12. lori (6)
  13. phrobb_ (6)
  14. mohnish (5)
  15. ghall (4)
  16. jmedved (4)
  17. dlenrow (3)
  18. LuisGomez (3)
  19. tykeal- (2)
  20. jamoluhrsen (2)
  21. giorgiogarziano (2)
  22. afredette (1)
  23. zxiiro (1)
  24. RPenno (1)
  25. phrobb (0)
  26. anipbu (0)


Generated by MeetBot 0.1.4.