========================== #opendaylight-meeting: tsc ========================== Meeting started by colindixon at 17:00:30 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-meeting/2015/tsc/opendaylight-meeting-tsc.2015-07-16-17.00.log.html . Meeting summary --------------- * agenda bashing and roll call (colindixon, 17:00:41) * regXboi (thinks he's edwarnicke) (regXboi, 17:00:46) * LINK: 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) * dfarrell07 for cdub/Red Hat (dfarrell07, 17:00:53) * LINK: https://wiki.opendaylight.org/index.php?title=TSC:Main&oldid=33638#Agenda the agenda in it’s usual place (colindixon, 17:01:01) * dlenrow (dlenrow, 17:01:05) * colindixon (colindixon, 17:01:12) * abhijitkumbhare for Chris Price / Ericsson (abhijitkumbhare, 17:01:18) * 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) * ACTION: ChrisPriceAB to work with rovarga, jmedved, et. al. to look into leveraging OPNFV infrastructure for performance measurements and (colindixon, 17:01:25) * mohnish anumala (mohnish, 17:01:38) * LuisGomez (LuisGomez, 17:02:18) * ACTION: gzhao to send out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t (colindixon, 17:02:58) * ACTION: phrobb and gzhao to beat the bushes to try to get cherry-picks out for Helium-SR4 (colindixon, 17:03:33) * 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) * 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) * 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) * snackewm (for Uri) (snackewm, 17:04:25) * ACTION: tony to send out an e-mail explaining his alternative solution to version bumping and branch cutting (colindixon, 17:04:46) * ACTION: regXboi to send out email on continuous release process (colindixon, 17:04:49) * events (colindixon, 17:06:33) * LINK: http://www.opendaylight.org/news/events/ ODL Events page (tbachman, 17:06:39) * CFP for OpenStack closed yesterday, hopefully people sent things in (colindixon, 17:06:56) * LINK: https://wiki.opendaylight.org/view/Events:Be_Dev_Forum pleas add developer design topics here (colindixon, 17:07:12) * 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) * IETF hackathon is on the 18th and 19th (this week). Contact Charles Eckel (eckelcu@cisco.com) for more information (tbachman, 17:08:16) * stable/helium and stable/lithium updates (colindixon, 17:08:24) * gzhao says that for stable/helium, we just need a date (colindixon, 17:08:36) * there have been some updates, but not a lot (colindixon, 17:08:47) * current currently schedule for 7/23 vote, which means cut on Sunday at 11:59p UTC (colindixon, 17:09:10) * colindixon asks if folks need more time to ship SR4, beyond the additional week already allocated (tbachman, 17:09:40) * abhijitkumbhare asks if it makes sense to ship Helium SR4 at the same time as the Lithium SR1 release (tbachman, 17:10:06) * 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) * dfarrell07 says he doesn’t believe there’s a stable release planned (tbachman, 17:10:48) * colindixon says his gut reaction is to ship SR4 with the current 1-week delay, unless he hears otherwise (tbachman, 17:11:46) * regXboi asks how long have we been holding SR4? (tbachman, 17:12:06) * colindixon says a long time — we’ve only slipped it once (tbachman, 17:12:18) * 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) * colindixon says yes (tbachman, 17:13:06) * LINK: https://lists.opendaylight.org/pipermail/release/2015-July/003076.html (colindixon, 17:13:18) * regXboi asks have we been in "last call" internally for more than two weeks (regXboi, 17:13:33) * LINK: 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) * regXboi says ship it (regXboi, 17:14:09) * dfarrell07 says ship it (dfarrell07, 17:14:25) * zxiiro asks if this is the last SR for stable/helium (tbachman, 17:14:45) * colindixon says yes (tbachman, 17:14:48) * 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) * colindixon says yes (tbachman, 17:15:17) * zxiiro says he’s on PTO next thursday, but could start that before he leaves (tbachman, 17:15:30) * LINK: 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) * it sounds like we might pus Lithium-SR1 back by a week to allow for more time after the summit (colindixon, 17:19:39) * we’ll cut the artifacts a full week in advance at 11:59p UTC to allow for time for testing (colindixon, 17:20:01) * regXboi says a project announces in M3 whether a feature is stable, but *when* does the TSC do the review? (regXboi, 17:23:02) * it’s evaluated by the TSC during the release review (colindixon, 17:23:19) * that means there needs to be a quorum of the TSC for those projects (regXboi, 17:23:52) * to be clear, a project must be mature to have stable feautres, not the other way around (colindixon, 17:27:06) * dfarrell07 asks how often and when are we reviewing stable feautres to be stabel again (colindixon, 17:27:42) * colindixon answers that stable features will be reviewed per-release (dfarrell07, 17:28:35) * stable features are only defined in the context of Be at teh meoment (colindixon, 17:28:37) * if we copy it moving forward, we will re-review stable stable features per-release (colindixon, 17:29:00) * 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) * colindixon says his gut reaction is no, but he’s open to other arguments (colindixon, 17:29:48) * LuisGomez sees no reason not to allow (colindixon, 17:29:54) * 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) * abhijitkumbhare asks for clarification how feature maturity affects karaf distribution (tbachman, 17:32:05) * colindixon says there will be two karaf feature repositories — one for stable features, and another for non-stable features (tbachman, 17:32:33) * 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) * 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) * phrobb notes the changes would need to occur in our karaf distributions and their testing well as documentation (tbachman, 17:34:08) * 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) * 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) * did you just chop M1 time by 2 weeks? (regXboi, 17:35:35) * colindixon says there are 3 +1 votes to the release plan on the mailing list (tbachman, 17:35:39) * I will now channel edwarnicke and say "you can't do that" (regXboi, 17:36:11) * colindixon says that the release plan has been available for some time (tbachman, 17:36:20) * regXboi says he is channelling edwarnicke :) (regXboi, 17:36:52) * 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) * 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) * regXboi's vote is based on his understanding of edwarnicke's opinions about dates (regXboi, 17:40:48) * Fabric as a Service Creation Review (tbachman, 17:41:31) * LINK: https://wiki.opendaylight.org/view/Project_Proposals:FaaS project proposal (colindixon, 17:41:40) * LINK: https://lists.opendaylight.org/pipermail/project-proposals/2015-June/000323.html proposed on 6/29/2015 (colindixon, 17:42:03) * ACTION: xingjun will post the slides on the wiki project proposal after the review (colindixon, 17:42:50) * 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) * 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) * The network is falling behind (tbachman, 17:43:46) * 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) * 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) * multi layer abstraction is required, no one layer fits all (tbachman, 17:46:53) * 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) * Fabric is a set of network resources (usually network node and topology between them) within the same control plane (tbachman, 17:50:21) * A fabric is a self-managed unit (tbachman, 17:50:29) * a fabric has a logical centralized management interface/control logic/state (tbachman, 17:50:40) * a fabric provides common network services (connectivity — L2/L3 logical network element: logical switch, logical router, gateway, tunnel end points) (tbachman, 17:51:22) * a Fabric manager manges fabric — CRUD operations of fabric objects (tbachman, 17:51:39) * Orchestrate/coordinate services across multiple fabrics (tbachman, 17:52:01) * resource manaagement occurs across fabric (tbachman, 17:52:11) * The fabric manager interacts with other dependent ODl modules (tbachman, 17:52:28) * The deliverables are are FaaS yang models and a Fabric Manager module (tbachman, 17:53:16) * The FaaS has an existing code base — UI, model, code for VLAN, and Fabric Manager (tbachman, 17:55:00) * 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) * xingjun says they’re going to leverage existing SB plugins in ODL — OVSDB and openflow to support openflow switches (tbachman, 17:56:17) * LuisGomez says in the scope of this release those two implementations should be available (tbachman, 17:56:33) * 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) * xingjun says they don’t overlap (tbachman, 17:57:23) * colindixon says there might be differences, but they definitely overlap (tbachman, 17:57:32) * one question is how would they co-exist? (regXboi, 17:57:49) * xingjun says they complement each other — one layer can’t solve all the problems. (tbachman, 17:58:00) * dlenrow says that’s why the other projects exist — the map an abstraction onto the SB protocols (tbachman, 17:58:15) * 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) * 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) * xingjun says you could use GBP to map the model as a service if you want (tbachman, 18:01:05) * dlenrow asks if all the existing projects (GBP, OVSDB-net-virt, VTN) would use this new FaaS? (tbachman, 18:01:37) * xingjun yes, that’s a possibility (tbachman, 18:01:42) * 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) * 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) * 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) * LuisGomez says we already have this issue in ODL (tbachman, 18:03:47) * 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. Action items, by person ----------------------- * colindixon * colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR1) * 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 * gzhao * gzhao to send out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t * phrobb and gzhao to beat the bushes to try to get cherry-picks out for Helium-SR4 * phrobb * phrobb and gzhao to beat the bushes to try to get cherry-picks out for Helium-SR4 * 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 * regXboi * regXboi to send out email on continuous release process * **UNASSIGNED** * ChrisPriceAB to work with rovarga, jmedved, et. al. to look into leveraging OPNFV infrastructure for performance measurements and * 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 * tony to send out an e-mail explaining his alternative solution to version bumping and branch cutting * xingjun will post the slides on the wiki project proposal after the review People present (lines said) --------------------------- * tbachman (106) * colindixon (81) * regXboi (41) * odl_meetbot (17) * dfarrell07 (13) * abhijitkumbhare (8) * gzhao (6) * ebrjohn (3) * mohnish (3) * dlenrow (2) * icbts (2) * phrobb (2) * LuisGomez (2) * hideyuki (2) * snackewm (2) Generated by `MeetBot`_ 0.1.4