17:00:30 #startmeeting tsc 17:00:30 Meeting started Thu Jul 16 17:00:30 2015 UTC. The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html. 17:00:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:30 The meeting name has been set to 'tsc' 17:00:41 #topic agenda bashing and roll call 17:00:46 #info regXboi (thinks he's edwarnicke) 17:00:48 #link https://meetings.opendaylight.org/opendaylight-meeting/2015/tsc/opendaylight-meeting-tsc.2015-07-09-17.00.html Minutes from last week’s meeting 17:00:53 #info dfarrell07 for cdub/Red Hat 17:01:01 #link https://wiki.opendaylight.org/index.php?title=TSC:Main&oldid=33638#Agenda the agenda in it’s usual place 17:01:05 #info dlenrow 17:01:12 #info colindixon 17:01:14 4 17:01:18 #info abhijitkumbhare for Chris Price / Ericsson 17:01:20 #action colindixon to try to find somebody to help with documenting the general procedure for the platform upgrade from Helium to Lithium (for SR1) 17:01:25 #action ChrisPriceAB to work with rovarga, jmedved, et. al. to look into leveraging OPNFV infrastructure for performance measurements and 17:01:38 #info mohnish anumala 17:01:41 6 17:02:16 phrobb: start recording? 17:02:18 #info LuisGomez 17:02:24 phrobb: having issues with audio? 17:02:33 colindixon: we're at 7 TSC members 17:02:44 working on it... 17:02:58 #action gzhao to send out exact cutoff dates/times for Lithium SRs and get him to if he hasn’t 17:03:33 #action phrobb and gzhao to beat the bushes to try to get cherry-picks out for Helium-SR4 17:03:57 #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 17:04:17 #info 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. 17:04:21 #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 17:04:25 #info snackewm (for Uri) 17:04:38 8 TSC members now 17:04:46 #action tony to send out an e-mail explaining his alternative solution to version bumping and branch cutting 17:04:49 #action regXboi to send out email on continuous release process 17:04:54 #action colindixon to resolve the scope change issue on the mailing list 17:06:00 Tab-p complete 17:06:04 colindixon: did you really mean to action "tony" rather than his IRC handle? 17:06:15 regXboi: yes, hes not here yet 17:06:23 #topic Updates 17:06:31 #undo 17:06:31 Removing item from minutes: 17:06:33 #topic events 17:06:39 #link http://www.opendaylight.org/news/events/ ODL Events page 17:06:56 #info CFP for OpenStack closed yesterday, hopefully people sent things in 17:07:12 #link https://wiki.opendaylight.org/view/Events:Be_Dev_Forum pleas add developer design topics here 17:07:18 colindixon: toofast 17:07:38 #info we need to be building the agenda for the dev forum in the next week, so sooner rather than later would be good 17:07:45 tbachman: must have a huge screen with tons of windows open. 17:07:49 yes 17:08:16 #info IETF hackathon is on the 18th and 19th (this week). Contact Charles Eckel (eckelcu@cisco.com) for more information 17:08:24 #topic stable/helium and stable/lithium updates 17:08:36 #info gzhao says that for stable/helium, we just need a date 17:08:47 #info there have been some updates, but not a lot 17:08:50 * tbachman welcomes back gzhao from well-deserved time off 17:09:10 #info current currently schedule for 7/23 vote, which means cut on Sunday at 11:59p UTC 17:09:15 gzhao: or very fast brain and fingers (which colindixon happens to posses) 17:09:35 I know of no reason to delay shipping it 17:09:40 #info colindixon asks if folks need more time to ship SR4, beyond the additional week already allocated 17:10:06 #info abhijitkumbhare asks if it makes sense to ship Helium SR4 at the same time as the Lithium SR1 release 17:10:33 #info gzhao says OPNFV has released ARNO — asks when their first stable release occurs, which may be important, given that ODL is their upstream 17:10:48 #info dfarrell07 says he doesn’t believe there’s a stable release planned 17:11:46 #info colindixon says his gut reaction is to ship SR4 with the current 1-week delay, unless he hears otherwise 17:12:06 #info regXboi asks how long have we been holding SR4? 17:12:18 #info colindixon says a long time — we’ve only slipped it once 17:12:34 was it regXboi or some other Ryan? 17:12:42 abhijitkumbhare: it was regXboi 17:12:53 OK 17:13:03 #info 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? 17:13:06 #info colindixon says yes 17:13:16 * regXboi going IRC only 17:13:18 https://lists.opendaylight.org/pipermail/release/2015-July/003076.html 17:13:20 regXboi: here’s the link 17:13:33 #info regXboi asks have we been in "last call" internally for more than two weeks 17:13:40 #link : https://lists.opendaylight.org/pipermail/release/2015-July/003076.html Email asking for last call for SR4 17:13:47 #undo 17:13:47 Removing item from minutes: 17:13:48 #link https://lists.opendaylight.org/pipermail/release/2015-July/003076.html colindixon says we’ve been doing last call for SR4 since July 1st 17:13:52 thx 17:13:58 ok - yes we have - I say ship it 17:13:58 * dfarrell07 suggest we just ship it 17:14:09 #info regXboi says ship it 17:14:25 #info dfarrell07 says ship it 17:14:45 #info zxiiro asks if this is the last SR for stable/helium 17:14:48 #info colindixon says yes 17:15:17 #info zxiiro says the reason for his question is because he’s wondering if we need to do version bumps post release 17:15:17 #info colindixon says yes 17:15:27 * ebrjohn trying not to imagine those guys do "The version bump dance"... 17:15:30 #info zxiiro says he’s on PTO next thursday, but could start that before he leaves 17:15:35 zxiiro: isn’t the release 8/20? 17:15:49 oh 17:15:50 :) 17:16:46 so, artifacts 7/19, blessed on 7/23? 17:16:59 tbachman: yes 17:17:26 #agreed stable/helium SR4 will cut artifacts on 7/19/2015 at 11:59UTC, and the TSC will vote on the release on 7/23/2015 at the TSC meeting, and zxiiro will bump versions sometime after that 17:17:45 I can do undo 17:17:50 It's past tense 17:18:04 * tbachman goes back to check meeting minutes 17:18:06 agreed works 17:18:49 colindixon: it’s agreed 17:19:03 * ebrjohn agreeing that agreed agrees 17:19:23 #link https://lists.opendaylight.org/pipermail/release/2015-July/003138.html this is the start of the discussion for Lithium-SR1 timing 17:19:39 #info it sounds like we might pus Lithium-SR1 back by a week to allow for more time after the summit 17:19:47 tbachman: not back yet, still in Shanghai, and no V for me. 17:20:01 #info we’ll cut the artifacts a full week in advance at 11:59p UTC to allow for time for testing 17:20:18 is it just me or is there a horrible echo? 17:20:21 #topic System Integration and Testing 17:20:31 regXboi: everything is good on my end 17:20:41 regXboi: I dont hear any echo 17:20:44 regXboi: I don't hear any echo. 17:20:50 wow 17:20:55 colindixon: then it must be my connection - colindixon is in double or triple echo 17:20:56 I just got a flood of IRC 17:21:03 * tbachman has a flakey connection, it appears 17:21:33 Stable Feature: A Top-Level Feature that meets the following criteria. The TSC is expected to review each potentially stable feature during the project's release review and ensure that it meets these requirements. Note: Any of these requirements can be waived by the TSC for a given feature. However, the TSC is encouraged to find a way to make the test fit the situation before granting a waiver. 17:22:07 but when does that happen? 17:22:15 M3 !?!?!?!?!?! 17:22:18 List all top-level, user-facing, and stable Karaf features for your project. 17:22:29 wait 17:22:51 regXboi: you have to say that you intend to have a feature stabe at M3 17:23:02 #info regXboi says a project announces in M3 whether a feature is stable, but *when* does the TSC do the review? 17:23:03 regXboi: you don’t need to meet the requirements 17:23:19 #info it’s evaluated by the TSC during the release review 17:23:45 * tbachman is suffering internetz hiccups 17:23:52 #info that means there needs to be a quorum of the TSC for those projects 17:24:01 regXboi: yes 17:24:40 * regXboi thinks about the implications 17:25:10 release reviews for mature projects should be during times when a majority of the TSC is around, e.g., during a TSC meeting 17:25:17 is there a conversation going on in another channel? 17:26:18 regXboi: there is a conversation on the webex which seems to be going well 17:26:39 the webex chat? 17:26:51 no webex voice 17:26:59 ok - I'm not hearing a lot of it :( 17:27:06 #info to be clear, a project must be mature to have stable feautres, not the other way around 17:27:07 regXboi: me as well :( 17:27:12 so it need to be reflected in the IRC 17:27:16 er *needs* 17:27:42 #info dfarrell07 asks how often and when are we reviewing stable feautres to be stabel again 17:27:58 so whoever is answering LuisGomez right now, I can't hear 17:28:13 regXboi: I think it’s colindixon 17:28:17 that’s me 17:28:26 colindixon: I only hear part of you 17:28:35 #info colindixon answers that stable features will be reviewed per-release 17:28:37 #info stable features are only defined in the context of Be at teh meoment 17:28:38 I see you talking :) 17:28:45 split horizon :) 17:28:59 regXboi: net neutrality available in your area? 17:29:00 abhijitkumbhare: either that or cache poisoning :) 17:29:00 #info if we copy it moving forward, we will re-review stable stable features per-release 17:29:24 tbachman: in a work office? really? :) 17:29:31 lol 17:29:31 #info LuisGomez asks if a feature could move to beign stable in an SR even if they aren’t stable in the main release 17:29:48 #info colindixon says his gut reaction is no, but he’s open to other arguments 17:29:54 #info LuisGomez sees no reason not to allow 17:30:03 yes - adding tests is explicitly allowed as part of an SR 17:30:27 regXboi: adding the tests is certainly allowed 17:30:48 regXboi: teh question is whether they can get tagged as stable formally by the TSC 17:30:56 #info 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 17:31:00 phrobb: did I get that right? 17:31:03 tbachman: thanks! 17:31:04 yes 17:31:08 tbachman: that sounds correct 17:31:25 * tbachman could hear phrobb :) 17:31:53 * icbts stable and unstable repos ? 17:32:05 #info abhijitkumbhare asks for clarification how feature maturity affects karaf distribution 17:32:33 #info colindixon says there will be two karaf feature repositories — one for stable features, and another for non-stable features 17:32:55 #info colindixon says there will also be two distributions — one that is just stable features, and another that includes nono-stable features 17:33:04 Sounds good :) 17:33:30 tbachman yes, the changes would need to occur in our karaf distributions and their testing well as documentation 17:33:42 #info LuisGomez says a stable feature is not declared until the end of a release, which makes it tough to include in the release 17:34:08 #info phrobb notes the changes would need to occur in our karaf distributions and their testing well as documentation 17:34:33 #info colindixon says an advantage of stable features means a stable distribution which (in theory) means that it’s less likely to break 17:34:59 #info regXboi asks a bigger question - is the Be plan being voted on as written, or will the dates be adjusted by 2 weeks? 17:35:12 regXboi: I was going to say as written 17:35:17 um 17:35:35 #info did you just chop M1 time by 2 weeks? 17:35:39 #info colindixon says there are 3 +1 votes to the release plan on the mailing list 17:36:11 #info I will now channel edwarnicke and say "you can't do that" 17:36:20 #info colindixon says that the release plan has been available for some time 17:36:52 #info regXboi says he is channelling edwarnicke :) 17:37:00 * tbachman thinks someone was trying to talk, but couldn’t hear them 17:37:13 tbachman: I'm writing on IRC and not talking 17:37:49 colindixon: if we've voted on the mailing list, how should we vote/not-vote/etc? 17:38:06 does anyone have any more questions or comments before a vote? 17:38:24 how’s this: Should the TSC approve the Beryllium Release Plan, as per this email: https://lists.opendaylight.org/pipermail/tsc/2015-July/003453.html ? +1, 0, -1 17:38:34 #startvote Should the TSC approve the Beryllium Release Plan, as per this email: https://lists.opendaylight.org/pipermail/tsc/2015-July/003453.html ? +1, 0, -1 17:38:35 Only the meeting chair may start a vote. 17:38:39 :( 17:38:43 #chair tbachman 17:38:43 Current chairs: colindixon tbachman 17:38:45 Should the TSC approve the Beryllium Release Plan, as per this email: https://lists.opendaylight.org/pipermail/tsc/2015-July/003453.html ? +1, 0, -1 17:38:49 #startvote Should the TSC approve the Beryllium Release Plan, as per this email: https://lists.opendaylight.org/pipermail/tsc/2015-July/003453.html ? +1, 0, -1 17:38:49 Begin voting on: Should the TSC approve the Beryllium Release Plan, as per this email: https://lists.opendaylight.org/pipermail/tsc/2015-July/003453.html ? Valid vote options are +1, 0, -1. 17:38:49 Vote using '#vote OPTION'. Only your last vote counts. 17:38:51 ask and ye shall receive ;) 17:38:55 #vote +1 17:38:56 #vote +1 17:38:57 #vote -1 17:38:58 #vote +1 17:39:02 #vote +1 17:39:04 #vote +1 17:39:06 #vote +1 17:39:27 #vote +1 17:39:39 #endvote 17:39:39 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 17:39:39 +1 (7): dlenrow, LuisGomez, dfarrell07, mohnish, colindixon, abhijitkumbhare, snackewm 17:39:39 -1 (1): regXboi 17:39:50 #agreed The TSC approves the Beryllium Release Plan, as per this email: https://lists.opendaylight.org/pipermail/tsc/2015-July/003453.html 17:40:34 regXboi: you represented edwarnicke well :) 17:40:48 #info regXboi's vote is based on his understanding of edwarnicke's opinions about dates 17:41:11 #topic Infrastructure 17:41:12 Oops 17:41:15 #undo 17:41:15 Removing item from minutes: 17:41:26 pointer to slides and project plan? 17:41:31 #topic Fabric as a Service Creation Review 17:41:40 #link https://wiki.opendaylight.org/view/Project_Proposals:FaaS project proposal 17:41:45 can we mute david lenrow? 17:41:53 phrobb: ^^ 17:42:03 #link https://lists.opendaylight.org/pipermail/project-proposals/2015-June/000323.html proposed on 6/29/2015 17:42:06 * tbachman wonders if dlenrow is climbing the newly changed half-dome? 17:42:15 xingjun 17:42:17 david.lenrow: thanks 17:42:21 who is speaking? (who is representating FaaS?) 17:42:27 #action xingjun will post the slides after the review 17:42:28 abhijitkumbhare: xingjun 17:42:31 OK 17:42:36 put the slides on the wiki page 17:42:39 #undo 17:42:39 Removing item from minutes: 17:42:50 #action xingjun will post the slides on the wiki project proposal after the review 17:43:28 #info problem statement is that is that nthe network is falling bheind int terms of capex/opex reduction, agaility and vendor lock-in 17:43:37 abhijitkumbhare: name: Xingjun Chu IRC handle xingjun 17:43:40 #info 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 17:43:46 #info The network is falling behind 17:43:49 thx gzhao 17:43:52 tbachman: it’s all yours 17:43:56 colindixon: :) 17:44:30 #info Network Service Operation Today: using low-level tools/APIs/interfaces (e.g. CLI); heavily depends on manual work, wtih no service agility 17:46:40 #info 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 17:46:53 #info multi layer abstraction is required, no one layer fits all 17:49:13 what’s a CT? 17:49:54 #info Fabric as a Service is a bottom-up abstraction — keep network primitives familiar to CT personell; defines FaaS model — unified service via Fabric 17:50:21 #info Fabric is a set of network resources (usually network node and topology between them) within the same control plane 17:50:29 #info A fabric is a self-managed unit 17:50:40 #info a fabric has a logical centralized management interface/control logic/state 17:50:59 colindixon: Communication Technology? i'm not sure. 17:51:22 #info a fabric provides common network services (connectivity — L2/L3 logical network element: logical switch, logical router, gateway, tunnel end points) 17:51:39 #info a Fabric manager manges fabric — CRUD operations of fabric objects 17:51:50 colindixon: normally we use IT and CT 17:52:01 #info Orchestrate/coordinate services across multiple fabrics 17:52:07 hideyuki: yes, communication technology 17:52:11 #info resource manaagement occurs across fabric 17:52:28 #info The fabric manager interacts with other dependent ODl modules 17:53:16 #info The deliverables are are FaaS yang models and a Fabric Manager module 17:55:00 #info The FaaS has an existing code base — UI, model, code for VLAN, and Fabric Manager 17:55:41 #info LuisGomez asks what protocols and devinces are they planning to target first? 17:55:44 +10 17:55:48 #info 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.) 17:55:57 #undo 17:55:57 Removing item from minutes: 17:56:04 #undo 17:56:04 Removing item from minutes: 17:56:09 #info 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.) 17:56:17 #info xingjun says they’re going to leverage existing SB plugins in ODL — OVSDB and openflow to support openflow switches 17:56:33 #info LuisGomez says in the scope of this release those two implementations should be available 17:57:10 #info 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 17:57:23 #info xingjun says they don’t overlap 17:57:32 #info colindixon says there might be differences, but they definitely overlap 17:57:49 #info one question is how would they co-exist? 17:58:00 #info xingjun says they complement each other — one layer can’t solve all the problems. 17:58:00 regXboi: good question 17:58:15 #info dlenrow says that’s why the other projects exist — the map an abstraction onto the SB protocols 17:58:57 #info colindixon notes that he was asking for his edification, historically, the TSC does not mandate that incubation projects have nonoverlapping scope 17:59:23 #info 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? 17:59:29 tbachman: thanks! 18:00:19 tsc members, are we comfortable voting now, or do we want to move it to the mailing list or next week’s meeting? 18:00:57 colindixon: I think I may want some ML time 18:01:02 this topic looks like require more discussion 18:01:05 yeah 18:01:05 #info xingjun says you could use GBP to map the model as a service if you want 18:01:06 +1 18:01:37 #info dlenrow asks if all the existing projects (GBP, OVSDB-net-virt, VTN) would use this new FaaS? 18:01:42 #info xingjun yes, that’s a possibility 18:02:40 #info 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 18:03:04 +1 to starting thread to talk about this more on the mailing list 18:03:08 #info colindixon says there are some TSC members who would like to see more discussion on the project over the mailing list before voting 18:03:36 #info 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 18:03:47 #info LuisGomez says we already have this issue in ODL 18:03:53 #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 18:04:55 #action colindixon to start a thread on the TSC mailing list on the FaaS project proposal 18:05:03 #undo 18:05:03 Removing item from minutes: 18:05:15 #endmeeting