#opendaylight-meeting: tsc

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

Meeting summary

  1. agenda bashing and roll call (colindixon, 17:00:41)
    1. regXboi (thinks he's edwarnicke) (regXboi, 17:00:46)
    2. https://meetings.opendaylight.org/opendaylight-meeting/2015/tsc/opendaylight-meeting-tsc.2015-07-09-17.00.html Minutes from last week’s meeting (tbachman, 17:00:48)
    3. dfarrell07 for cdub/Red Hat (dfarrell07, 17:00:53)
    4. https://wiki.opendaylight.org/index.php?title=TSC:Main&oldid=33638#Agenda the agenda in it’s usual place (colindixon, 17:01:01)
    5. dlenrow (dlenrow, 17:01:05)
    6. colindixon (colindixon, 17:01:12)
    7. abhijitkumbhare for Chris Price / Ericsson (abhijitkumbhare, 17:01:18)
    8. ACTION: colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR1) (colindixon, 17:01:20)
    9. ACTION: ChrisPriceAB to work with rovarga, jmedved, et. al. to look into leveraging OPNFV infrastructure for performance measurements and (colindixon, 17:01:25)
    10. mohnish anumala (mohnish, 17:01:38)
    11. LuisGomez (LuisGomez, 17:02:18)
    12. ACTION: gzhao to send out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t (colindixon, 17:02:58)
    13. ACTION: phrobb and gzhao to beat the bushes to try to get cherry-picks out for Helium-SR4 (colindixon, 17:03:33)
    14. ACTION: phrobb to send out mail when the new infra person is up-to-speed so that he knows when he will not be waking people up after hours (colindixon, 17:03:57)
    15. colindixon and dfarrell07 talked about past #action to notify projects of test failures. We already do that via the Jenkins mailing list and topics. Documented it better in project getting started wiki. (dfarrell07, 17:04:17)
    16. ACTION: tony and zxiiro to look at the sonar/jacoco reports and try to figure out how (and if) we can reasonby get feature-level code coverage information (colindixon, 17:04:21)
    17. snackewm (for Uri) (snackewm, 17:04:25)
    18. ACTION: tony to send out an e-mail explaining his alternative solution to version bumping and branch cutting (colindixon, 17:04:46)
    19. ACTION: regXboi to send out email on continuous release process (colindixon, 17:04:49)

  2. events (colindixon, 17:06:33)
    1. http://www.opendaylight.org/news/events/ ODL Events page (tbachman, 17:06:39)
    2. CFP for OpenStack closed yesterday, hopefully people sent things in (colindixon, 17:06:56)
    3. https://wiki.opendaylight.org/view/Events:Be_Dev_Forum pleas add developer design topics here (colindixon, 17:07:12)
    4. we need to be building the agenda for the dev forum in the next week, so sooner rather than later would be good (colindixon, 17:07:38)
    5. IETF hackathon is on the 18th and 19th (this week). Contact Charles Eckel (eckelcu@cisco.com) for more information (tbachman, 17:08:16)

  3. stable/helium and stable/lithium updates (colindixon, 17:08:24)
    1. gzhao says that for stable/helium, we just need a date (colindixon, 17:08:36)
    2. there have been some updates, but not a lot (colindixon, 17:08:47)
    3. current currently schedule for 7/23 vote, which means cut on Sunday at 11:59p UTC (colindixon, 17:09:10)
    4. colindixon asks if folks need more time to ship SR4, beyond the additional week already allocated (tbachman, 17:09:40)
    5. abhijitkumbhare asks if it makes sense to ship Helium SR4 at the same time as the Lithium SR1 release (tbachman, 17:10:06)
    6. gzhao says OPNFV has released ARNO — asks when their first stable release occurs, which may be important, given that ODL is their upstream (tbachman, 17:10:33)
    7. dfarrell07 says he doesn’t believe there’s a stable release planned (tbachman, 17:10:48)
    8. colindixon says his gut reaction is to ship SR4 with the current 1-week delay, unless he hears otherwise (tbachman, 17:11:46)
    9. regXboi asks how long have we been holding SR4? (tbachman, 17:12:06)
    10. colindixon says a long time — we’ve only slipped it once (tbachman, 17:12:18)
    11. regXboi asks how long have we gone through last call to wait for folks to make last call — has it been more than 2 weeks? (tbachman, 17:13:03)
    12. colindixon says yes (tbachman, 17:13:06)
    13. https://lists.opendaylight.org/pipermail/release/2015-July/003076.html (colindixon, 17:13:18)
    14. regXboi asks have we been in "last call" internally for more than two weeks (regXboi, 17:13:33)
    15. https://lists.opendaylight.org/pipermail/release/2015-July/003076.html colindixon says we’ve been doing last call for SR4 since July 1st (colindixon, 17:13:48)
    16. regXboi says ship it (regXboi, 17:14:09)
    17. dfarrell07 says ship it (dfarrell07, 17:14:25)
    18. zxiiro asks if this is the last SR for stable/helium (tbachman, 17:14:45)
    19. colindixon says yes (tbachman, 17:14:48)
    20. zxiiro says the reason for his question is because he’s wondering if we need to do version bumps post release (tbachman, 17:15:17)
    21. colindixon says yes (tbachman, 17:15:17)
    22. zxiiro says he’s on PTO next thursday, but could start that before he leaves (tbachman, 17:15:30)
    23. https://lists.opendaylight.org/pipermail/release/2015-July/003138.html this is the start of the discussion for Lithium-SR1 timing (colindixon, 17:19:23)
    24. it sounds like we might pus Lithium-SR1 back by a week to allow for more time after the summit (colindixon, 17:19:39)
    25. we’ll cut the artifacts a full week in advance at 11:59p UTC to allow for time for testing (colindixon, 17:20:01)
    26. regXboi says a project announces in M3 whether a feature is stable, but *when* does the TSC do the review? (regXboi, 17:23:02)
    27. it’s evaluated by the TSC during the release review (colindixon, 17:23:19)
    28. that means there needs to be a quorum of the TSC for those projects (regXboi, 17:23:52)
    29. to be clear, a project must be mature to have stable feautres, not the other way around (colindixon, 17:27:06)
    30. dfarrell07 asks how often and when are we reviewing stable feautres to be stabel again (colindixon, 17:27:42)
    31. colindixon answers that stable features will be reviewed per-release (dfarrell07, 17:28:35)
    32. stable features are only defined in the context of Be at teh meoment (colindixon, 17:28:37)
    33. if we copy it moving forward, we will re-review stable stable features per-release (colindixon, 17:29:00)
    34. LuisGomez asks if a feature could move to beign stable in an SR even if they aren’t stable in the main release (colindixon, 17:29:31)
    35. colindixon says his gut reaction is no, but he’s open to other arguments (colindixon, 17:29:48)
    36. LuisGomez sees no reason not to allow (colindixon, 17:29:54)
    37. phrobb says from his standpoint, the question is back to the integration team — if we allow a feature to become stable, as it changes where it is in the karaf distribution (tbachman, 17:30:56)
    38. abhijitkumbhare asks for clarification how feature maturity affects karaf distribution (tbachman, 17:32:05)
    39. colindixon says there will be two karaf feature repositories — one for stable features, and another for non-stable features (tbachman, 17:32:33)
    40. colindixon says there will also be two distributions — one that is just stable features, and another that includes nono-stable features (tbachman, 17:32:55)
    41. LuisGomez says a stable feature is not declared until the end of a release, which makes it tough to include in the release (tbachman, 17:33:42)
    42. phrobb notes the changes would need to occur in our karaf distributions and their testing well as documentation (tbachman, 17:34:08)
    43. colindixon says an advantage of stable features means a stable distribution which (in theory) means that it’s less likely to break (tbachman, 17:34:33)
    44. regXboi asks a bigger question - is the Be plan being voted on as written, or will the dates be adjusted by 2 weeks? (regXboi, 17:34:59)
    45. did you just chop M1 time by 2 weeks? (regXboi, 17:35:35)
    46. colindixon says there are 3 +1 votes to the release plan on the mailing list (tbachman, 17:35:39)
    47. I will now channel edwarnicke and say "you can't do that" (regXboi, 17:36:11)
    48. colindixon says that the release plan has been available for some time (tbachman, 17:36:20)
    49. regXboi says he is channelling edwarnicke :) (regXboi, 17:36:52)
    50. VOTE: Voted on "Should the TSC approve the Beryllium Release Plan, as per this email: https://lists.opendaylight.org/pipermail/tsc/2015-July/003453.html ?" Results are, +1: 7, -1: 1 (tbachman, 17:39:39)
    51. AGREED: The TSC approves the Beryllium Release Plan, as per this email: https://lists.opendaylight.org/pipermail/tsc/2015-July/003453.html (tbachman, 17:39:50)
    52. regXboi's vote is based on his understanding of edwarnicke's opinions about dates (regXboi, 17:40:48)

  4. Fabric as a Service Creation Review (tbachman, 17:41:31)
    1. https://wiki.opendaylight.org/view/Project_Proposals:FaaS project proposal (colindixon, 17:41:40)
    2. https://lists.opendaylight.org/pipermail/project-proposals/2015-June/000323.html proposed on 6/29/2015 (colindixon, 17:42:03)
    3. ACTION: xingjun will post the slides on the wiki project proposal after the review (colindixon, 17:42:50)
    4. problem statement is that is that nthe network is falling bheind int terms of capex/opex reduction, agaility and vendor lock-in (colindixon, 17:43:28)
    5. The problem statement is that the computing paradigm is evolving inside and outside the Data Center: CAPEX/OPEX reduction; Service agility/Automation/Efficiency; No vendor lock-in (tbachman, 17:43:40)
    6. The network is falling behind (tbachman, 17:43:46)
    7. Network Service Operation Today: using low-level tools/APIs/interfaces (e.g. CLI); heavily depends on manual work, wtih no service agility (tbachman, 17:44:30)
    8. Industry Initiatives/Solutions: SDN-1 (Control and Data Plane separation) — protocol standardization; SDN-2 (APplication Centric Modeling) GBP/NIC/NEMO — top-down approaches, monolithic solution and coupled with low-level primitives, making it hard to implement on 3rd psrty devices (tbachman, 17:46:40)
    9. multi layer abstraction is required, no one layer fits all (tbachman, 17:46:53)
    10. Fabric as a Service is a bottom-up abstraction — keep network primitives familiar to CT personell; defines FaaS model — unified service via Fabric (tbachman, 17:49:54)
    11. Fabric is a set of network resources (usually network node and topology between them) within the same control plane (tbachman, 17:50:21)
    12. A fabric is a self-managed unit (tbachman, 17:50:29)
    13. a fabric has a logical centralized management interface/control logic/state (tbachman, 17:50:40)
    14. a fabric provides common network services (connectivity — L2/L3 logical network element: logical switch, logical router, gateway, tunnel end points) (tbachman, 17:51:22)
    15. a Fabric manager manges fabric — CRUD operations of fabric objects (tbachman, 17:51:39)
    16. Orchestrate/coordinate services across multiple fabrics (tbachman, 17:52:01)
    17. resource manaagement occurs across fabric (tbachman, 17:52:11)
    18. The fabric manager interacts with other dependent ODl modules (tbachman, 17:52:28)
    19. The deliverables are are FaaS yang models and a Fabric Manager module (tbachman, 17:53:16)
    20. The FaaS has an existing code base — UI, model, code for VLAN, and Fabric Manager (tbachman, 17:55:00)
    21. LuisGomez asks which protocol and devices are going to be targeted first — or is that specified in the project poroposal (e.g openflow, OVS, etc.) (colindixon, 17:56:09)
    22. xingjun says they’re going to leverage existing SB plugins in ODL — OVSDB and openflow to support openflow switches (tbachman, 17:56:17)
    23. LuisGomez says in the scope of this release those two implementations should be available (tbachman, 17:56:33)
    24. colindixon says there are 3 existing projects that do this: VTN , OVSDB net-virt, and GBP. Why is a new project needed rather than leveraging existing ones (tbachman, 17:57:10)
    25. xingjun says they don’t overlap (tbachman, 17:57:23)
    26. colindixon says there might be differences, but they definitely overlap (tbachman, 17:57:32)
    27. one question is how would they co-exist? (regXboi, 17:57:49)
    28. xingjun says they complement each other — one layer can’t solve all the problems. (tbachman, 17:58:00)
    29. dlenrow says that’s why the other projects exist — the map an abstraction onto the SB protocols (tbachman, 17:58:15)
    30. colindixon notes that he was asking for his edification, historically, the TSC does not mandate that incubation projects have nonoverlapping scope (colindixon, 17:58:57)
    31. regXboi asks in the Neutron example, neutron puts the information in the MD-SAL and make it available to all the conusming projects; how would FaaS coexist with GBP or OVSDB-net-virt or VTN? (tbachman, 17:59:23)
    32. xingjun says you could use GBP to map the model as a service if you want (tbachman, 18:01:05)
    33. dlenrow asks if all the existing projects (GBP, OVSDB-net-virt, VTN) would use this new FaaS? (tbachman, 18:01:37)
    34. xingjun yes, that’s a possibility (tbachman, 18:01:42)
    35. dlenrow says the NIC project plans to also build this functionality, and doesn’t plan to do it in a monolithic fashion, and don’t see the need for FaaS (tbachman, 18:02:40)
    36. colindixon says there are some TSC members who would like to see more discussion on the project over the mailing list before voting (tbachman, 18:03:08)
    37. regXboi says we need to be sure that this project has some way of coexsiting with other projects, and isn’t seeing it just yet (tbachman, 18:03:36)
    38. LuisGomez says we already have this issue in ODL (tbachman, 18:03:47)
    39. ACTION: colindixon to start a thead on the mailing list followed by a vote eithe ron the mailing list, followed by a vote on the mailing list and/or next week’s meeting (colindixon, 18:03:53)


Meeting ended at 18:05:15 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 SR1)
  2. ChrisPriceAB to work with rovarga, jmedved, et. al. to look into leveraging OPNFV infrastructure for performance measurements and
  3. gzhao to send out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t
  4. phrobb and gzhao to beat the bushes to try to get cherry-picks out for Helium-SR4
  5. phrobb to send out mail when the new infra person is up-to-speed so that he knows when he will not be waking people up after hours
  6. tony and zxiiro to look at the sonar/jacoco reports and try to figure out how (and if) we can reasonby get feature-level code coverage information
  7. tony to send out an e-mail explaining his alternative solution to version bumping and branch cutting
  8. regXboi to send out email on continuous release process
  9. xingjun will post the slides on the wiki project proposal after the review
  10. colindixon to start a thead on the mailing list followed by a vote eithe ron the mailing list, followed by a vote on the mailing list and/or next week’s meeting


Action items, by person

  1. colindixon
    1. colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR1)
    2. colindixon to start a thead on the mailing list followed by a vote eithe ron the mailing list, followed by a vote on the mailing list and/or next week’s meeting
  2. gzhao
    1. gzhao to send out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t
    2. phrobb and gzhao to beat the bushes to try to get cherry-picks out for Helium-SR4
  3. phrobb
    1. phrobb and gzhao to beat the bushes to try to get cherry-picks out for Helium-SR4
    2. phrobb to send out mail when the new infra person is up-to-speed so that he knows when he will not be waking people up after hours
  4. regXboi
    1. regXboi to send out email on continuous release process
  5. UNASSIGNED
    1. ChrisPriceAB to work with rovarga, jmedved, et. al. to look into leveraging OPNFV infrastructure for performance measurements and
    2. tony and zxiiro to look at the sonar/jacoco reports and try to figure out how (and if) we can reasonby get feature-level code coverage information
    3. tony to send out an e-mail explaining his alternative solution to version bumping and branch cutting
    4. xingjun will post the slides on the wiki project proposal after the review


People present (lines said)

  1. tbachman (106)
  2. colindixon (81)
  3. regXboi (41)
  4. odl_meetbot (17)
  5. dfarrell07 (13)
  6. abhijitkumbhare (8)
  7. gzhao (6)
  8. ebrjohn (3)
  9. mohnish (3)
  10. dlenrow (2)
  11. icbts (2)
  12. phrobb (2)
  13. LuisGomez (2)
  14. hideyuki (2)
  15. snackewm (2)


Generated by MeetBot 0.1.4.