#opendaylight-meeting: tsc

Meeting started by colindixon at 18:00:53 UTC (full logs).

Meeting summary

    1. Daniel Farrell (dfarrell07, 18:00:57)

  2. agenda bashing and roll call (colindixon, 18:00:58)
    1. colindixon (colindixon, 18:01:26)
    2. LuisGomez (LuisGomez, 18:01:35)
    3. https://wiki.opendaylight.org/index.php?title=TSC:Main&oldid=40433#Agenda the agenda in it's usual place (colindixon, 18:01:56)
    4. Chris price (ChrisPriceAB, 18:02:24)
    5. ACTION: colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade to Boron? (colindixon, 18:03:55)
    6. ACTION: colindixon to keep boron planning on our minds (colindixon, 18:04:04)
    7. ChrisPriceAB et al have made progress on Europe boot camp, will cycle back when there are updates (dfarrell07, 18:04:06)
    8. mohnish anumala (mohnish_, 18:04:28)
    9. eric multanen (snackewm, 18:04:34)
    10. edwarnicke (edwarnicke, 18:04:44)

  3. events (colindixon, 18:04:58)
    1. https://www.opendaylight.org/global-events (colindixon, 18:05:09)
    2. phrobb- is missed (edwarnicke, 18:05:18)
    3. https://www.opendaylight.org/events/2016-02-29-000000-2016-03-01-000000/opendaylight-developer-design-forum pleas register to attend an book travel for the developer designg forum on 2/29 and 3/1 (colindixon, 18:05:52)
    4. CFP for the OpenStack summit closes 2/1 (colindixon, 18:06:36)

  4. boron (colindixon, 18:08:05)
    1. branch cutting and version bumping was complete last week, but yang tools has asked to bump to 1.0.0 instead of 0.9.0 (colindixon, 18:08:51)
    2. zxiiro says he plans to do that bump today, he asks about date-based-versions, tony says it shoudl be gone now, so should be fine (colindixon, 18:09:33)
    3. tony says they're all now in MD-SAL (colindixon, 18:09:50)
    4. for what it's worth we now have master branches that will become Boron, we will remove the now unused pre-boron branches in 3 weeks (colindixon, 18:10:28)
    5. ACTION: zxiiro to start a thread on whether pre-boron and what we shoudl do in the future (colindixon, 18:10:52)
    6. rovarga_ says there are bunch fo projects to disable JDK7 verification for boron, he'd like them to do that (colindixon, 18:12:07)
    7. VOTE: Voted on "shall the TSC agree that we will not support JDK7 in Boron, it will focus on JDK8?" Results are, +1: 7 (colindixon, 18:13:19)
    8. AGREED: Boron will not support Java 7, it will target Java 8 (colindixon, 18:13:31)

  5. beryllium (colindixon, 18:13:58)
    1. merge jobs currently build with Java 7, while autorelease builds with Java 8, which means SNAPSHOTS are built from Java 7 while release artifacts are built with Java 8 (colindixon, 18:14:57)
    2. rovarga_ says for arcane reasons with maven embedding the build environment, we should actually build in autorelease with Java 7 instead of Java 8 (colindixon, 18:15:26)
    3. ACTION: zxiiro to move autorelease to building with Java 7 (colindixon, 18:16:10)
    4. build for RC0 will start at midnight UTC today, after that projects will be asked download and test later today or tomorrow (colindixon, 18:16:54)
    5. https://jenkins.opendaylight.org/releng/view/autorelease/job/autorelease-release-beryllium/22/ (anipbu, 18:17:05)
    6. we ask projects to test the autorelease beryllium build (above) for unstable tests (colindixon, 18:17:28)
    7. https://wiki.opendaylight.org/view/Weather#BUG-4295:_Lazy_Data_Tree_MERGE_operations (anipbu, 18:17:49)
    8. bug 4295 (above) was merged as a weather event, with no fallout observed yet other than one bug in NETCONF test (colindixon, 18:18:05)

  6. system integration and test (colindixon, 18:18:23)
    1. due to infrastructure issues, many CSIT tests weren't working, it seems to have been fixed last night and things seem pretty stable (colindixon, 18:18:43)
    2. there are still projects with no system tests at M5, there are other that have tests that do nothing (colindixon, 18:19:07)
    3. jamoluhrsen will follow up with people that don't have them (colindixon, 18:19:13)
    4. ACTION: jamoluhrsen and anipbu to make sure we have system test status, i.e., do they exist, tracked on the main spreadsheet so we can cover it next week (colindixon, 18:19:56)
    5. colindixon begs to reuse the main tracking sheet vs. creating a new (colindixon, 18:20:16)

  7. infrastructure (colindixon, 18:21:10)
    1. we've had issues all week causing all CSIT stuff to fail, there was a bug in neutron that caused VMs that came up in error states to not release their ports, and we ran out of ports pretty quickly (colindixon, 18:22:07)
    2. we still have that issue, but rackspace has a script to clean up the ports they can run when needed (colindixon, 18:22:35)
    3. colindixon asks how long we'll be OK, zxiiro says he doesn't know (colindixon, 18:23:04)
    4. this was affecting everything, but CSIT jobs were more likely to fail because they created more slaves (colindixon, 18:24:06)

  8. Stephen Kitt as a committer odlparent (colindixon, 18:24:25)
    1. https://lists.opendaylight.org/pipermail/tsc/2016-January/004559.html the ask for the vote (colindixon, 18:24:36)
    2. links to his work are in that e-mail (colindixon, 18:25:01)
    3. skitt also has patches to 30+ ODL projects (dfarrell07, 18:25:40)
    4. zxiiro and edwarnicke argue the case is pretty clear, ~50 patches merged and open to odlparent (colindixon, 18:25:53)
    5. VOTE: Voted on "shall the TSC approve Stephen Kitt as a committer on the odlparent project?" Results are, +1: 7 (colindixon, 18:26:39)
    6. AGREED: Stephen Kitt is now a comitter on odlparent (colindixon, 18:26:47)

  9. openflow plugin design conflict (colindixon, 18:27:09)
    1. https://lists.opendaylight.org/pipermail/release/2016-January/005241.html colin's summary (colindixon, 18:27:35)
    2. https://lists.opendaylight.org/pipermail/tsc/2016-January/004562.html colin's summary of the situation (colindixon, 18:30:16)
    3. we have two designes of the openflow plugin, unfortuntely we have 2 proejcts that cant use the new one (VTN and VPNService) and 2 projects that can't use the od one (DIDM and NIC) (colindixon, 18:30:56)
    4. hideyuki notes that the performance of the new one is poor (500ms to install a single flow) and there are some RPCs missing in the new one that they use, hideyuki says they'd need 2 weeks to migrate even if the performance issues went away (colindixon, 18:31:44)
    5. vishnoianil says as he understands it, the only blocking feature from the projects using the new plugin is sending table features messages and that could be added to the old plugin, then DIDM and NIC should be able to use the old plugin (colindixon, 18:33:34)
    6. ACTION: vishnoianil anipbu abhijitkumbhare to figure out if this will actually enable DIDM and NIC to fall back and then coording the effort (colindixon, 18:34:48)
    7. ACTION: anipbu to talk to the remaining 7 projects that haven't voted, but I *think* they're all using the old plugin, so this would work for them (colindixon, 18:35:32)
    8. anipbu notes that some support both, e.g., OVSDB (colindixon, 18:35:44)
    9. rovarga_ says that any project using FRM should get this for free, anyone using RPCs will have an easy migration, if you snoop on things like port_up and port_down that will be harder to migrate (colindixon, 18:36:38)
    10. dfarrell07 says one reason people moved to the new design was to suppport clustering, but there have been efforts to make clustering also work in the old design (colindixon, 18:37:25)
    11. LuisGomez sasy that neither one is totally stable in a cluster now (colindixon, 18:37:43)
    12. rovarga_ also notes that the openflowplugin project doesn't have the bandwidth to support both designs in the long run (colindixon, 18:38:14)
    13. I will note this is a reality now, even in short term I worry about sustainability here .. (rovarga_, 18:39:26)
    14. ACTION: colindixon to follow with this issue to figure out lessons learned and how to avoid this in the future (colindixon, 18:39:39)
    15. anipbu says that the end-goal as he understands it is to move to the lithium (new) deisgn (colindixon, 18:43:22)
    16. mohnish_ asks if we should strive to move foward not backward, e.g., get people to move to the new design instead of asking people to move backward (colindixon, 18:44:15)
    17. edwarnicke notes that this hits an annoying spot where both OpenFlow plugins need access to the relevant ports and that causes failures, so we need to agree on this, but our culture tends to let people disagre, hence this dilemma (colindixon, 18:47:47)
    18. rovarga_ asks if there are sane ways that you would load apps that use different plugins, ChrisPriceAB gives an example that he wants in OPNFV which might trigger things (colindixon, 18:48:57)
    19. in essense, I think rovarga_ says that we could maybe just provide a list of features and which plugin they use and that would then result in this being a non-issue because you won't ever load features that end up using both plugins (colindixon, 18:51:32)
    20. rovarga_ notes that it is likely that features using different versions of the OFplugin are already in conflict independent of the question of which OFplugin is used (edwarnicke, 18:51:35)
    21. ACTION: anipbu rovarga_ colindixon and others to reach out to figure out if it will suffice to have a list of features that use OpenFlow plugin and docuemnt which plugin to load for each feature to make sure that there are new conflicts, in which case we could move forward (colindixon, 18:53:34)
    22. note there are background conversations between hideyuki and rovarga_ about VTNs use fo openflow plugin (colindixon, 18:56:16)
    23. note there are background conversations between icbts and rovarga_ about Karaf issues with features and moving to Karaf 4 (colindixon, 18:57:36)
    24. as of now, we have established that only NIC and DIDM are really using (or testing) the new design, so this makes the two approaches somewhat saner than edwarnicke previously thought when he thought more people were were using an testing against the new design than that (colindixon, 19:02:29)

  10. cookies (colindixon, 19:04:42)


Meeting ended at 19:04:49 UTC (full logs).

Action items

  1. colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade to Boron?
  2. colindixon to keep boron planning on our minds
  3. zxiiro to start a thread on whether pre-boron and what we shoudl do in the future
  4. zxiiro to move autorelease to building with Java 7
  5. jamoluhrsen and anipbu to make sure we have system test status, i.e., do they exist, tracked on the main spreadsheet so we can cover it next week
  6. vishnoianil anipbu abhijitkumbhare to figure out if this will actually enable DIDM and NIC to fall back and then coording the effort
  7. anipbu to talk to the remaining 7 projects that haven't voted, but I *think* they're all using the old plugin, so this would work for them
  8. colindixon to follow with this issue to figure out lessons learned and how to avoid this in the future
  9. anipbu rovarga_ colindixon and others to reach out to figure out if it will suffice to have a list of features that use OpenFlow plugin and docuemnt which plugin to load for each feature to make sure that there are new conflicts, in which case we could move forward


Action items, by person

  1. abhijitkumbhare
    1. vishnoianil anipbu abhijitkumbhare to figure out if this will actually enable DIDM and NIC to fall back and then coording the effort
  2. anipbu
    1. jamoluhrsen and anipbu to make sure we have system test status, i.e., do they exist, tracked on the main spreadsheet so we can cover it next week
    2. vishnoianil anipbu abhijitkumbhare to figure out if this will actually enable DIDM and NIC to fall back and then coording the effort
    3. anipbu to talk to the remaining 7 projects that haven't voted, but I *think* they're all using the old plugin, so this would work for them
    4. anipbu rovarga_ colindixon and others to reach out to figure out if it will suffice to have a list of features that use OpenFlow plugin and docuemnt which plugin to load for each feature to make sure that there are new conflicts, in which case we could move forward
  3. colindixon
    1. colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade to Boron?
    2. colindixon to keep boron planning on our minds
    3. colindixon to follow with this issue to figure out lessons learned and how to avoid this in the future
    4. anipbu rovarga_ colindixon and others to reach out to figure out if it will suffice to have a list of features that use OpenFlow plugin and docuemnt which plugin to load for each feature to make sure that there are new conflicts, in which case we could move forward
  4. jamoluhrsen
    1. jamoluhrsen and anipbu to make sure we have system test status, i.e., do they exist, tracked on the main spreadsheet so we can cover it next week
  5. rovarga_
    1. anipbu rovarga_ colindixon and others to reach out to figure out if it will suffice to have a list of features that use OpenFlow plugin and docuemnt which plugin to load for each feature to make sure that there are new conflicts, in which case we could move forward
  6. UNASSIGNED
    1. zxiiro to start a thread on whether pre-boron and what we shoudl do in the future
    2. zxiiro to move autorelease to building with Java 7


People present (lines said)

  1. colindixon (80)
  2. odl_meetbot (14)
  3. dfarrell07 (11)
  4. rovarga_ (8)
  5. edwarnicke (7)
  6. hideyuki (4)
  7. ChrisPriceAB (4)
  8. icbts (3)
  9. LuisGomez (3)
  10. snackewm (3)
  11. mohnish_ (3)
  12. alagalah|alt (2)
  13. abhijitkumbhare (2)
  14. anipbu (2)
  15. dneary (1)
  16. jamoluhrsen (1)


Generated by MeetBot 0.1.4.