17:59:54 #startmeeting tsc 17:59:54 Meeting started Thu Dec 11 17:59:54 2014 UTC. The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html. 17:59:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:59:54 The meeting name has been set to 'tsc' 18:00:04 #topic roll call and agenda bashing 18:00:08 #info colindixon 18:00:23 #link https://wiki.opendaylight.org/view/TSC:Main the agenda in it’s usual place 18:00:33 #info dlenrow 18:01:16 feel free to chair me Colin 18:02:17 #info edwarnicke 18:02:27 #info kwatsen 18:02:29 #chair phrobb 18:02:29 Current chairs: colindixon phrobb 18:03:01 hand it to dfarrell07? he does good scribe as well ;) 18:03:08 I can do some 18:03:20 #info colindixon asks rexpugh and steve dean if they need to present their proposals today, they say no, but that they can if we have time 18:03:21 no hope of being as good as tbachman ;) 18:03:24 #chair dfarrell07 18:03:24 Current chairs: colindixon dfarrell07 phrobb 18:03:24 #chair dfarrell07 18:03:24 Current chairs: colindixon dfarrell07 phrobb 18:03:35 #info LuisGomez 18:03:36 * edwarnicke is pretty sure the rest of us are optional but tbachman is mandatory... 18:03:43 #link https://meetings.opendaylight.org/opendaylight-meeting/2014/tsc/opendaylight-meeting-tsc.2014-12-04-18.00.html meeting minutes from last week for action items 18:03:53 #info Youcef Laribi 18:04:43 #action colindixon to start the conversation and collect ideas on how to resolve cross-project version bumping in timely fashion 18:04:43 #undo 18:04:43 #action colindixon zxiiro mlemay and edwarnicke to work on better version management and version bumping and present it here 18:04:43 Removing item from minutes: 18:04:55 colindixon: we can't hear you 18:05:53 colindixon, we cannot hear you 18:06:10 Howdy y'all 18:06:29 He's on IRC mlemay 18:07:17 hey 18:07:22 I'm here 18:07:30 mlemay: They were asking about version bump 18:07:43 #info mohnish 18:07:44 ahhh yea can't join in voice.. but I'm here 18:07:47 #info Discussion about version bumping better with zxiiro mlemay and edwarnicke 18:08:08 #info Chris Price (apologies I'm late) 18:08:11 colindixon: I've been preempted at the last minute by a flash item, so I'm not on today's call or IRC meeting :/ 18:08:33 #info regXboi - here to apologize for not being here - and then running away 18:08:49 #info phrobb working with tykeal to get new certs for OSX, progress but no solution yet 18:09:04 about version bumping .. there is version of multiple things 18:09:16 (features vs bundles) mainly 18:09:31 mlemay: Have you looked at yangtools-artifacts, mdsal-artifacts, etc 18:09:53 these days in my locate pratices I must admit that on this less is more.. in other words the more yangtools-like it is the better 18:09:53 #info phrobb worked with CAPWAP to revise project proposal 18:10:00 mlemay: I agree though that there are subtlties to bundles vs features 18:10:07 * dfarrell07 needed a sec to figure out how to spell CAPWAP, lol 18:10:11 mlemay: I've hit that as I'm trying to use them 18:10:21 #action edwarnicke and jan medved to work with phrobb to the mac certificate issue 18:10:22 * colindixon is back 18:10:44 colindixon: I was only kidding about us not being able to run a TSC call without tbachman ? 18:10:53 edwarnicke: :-) 18:11:14 colindixon: I'll repeat my info - I'm not here - apologies - I've been pre-empted by a flash item - talk to folks next week 18:11:43 bye all 18:11:51 regXboi: bye :) 18:12:59 Am I right that the agenda hasn't been updated? https://wiki.opendaylight.org/view/TSC:Main 18:13:25 @edwarnicke: I did look into the artifacts (we are talking about yangtools/commons/artifacts) right? 18:13:34 saw and looked at the git reviews 18:13:49 #info colindixon hopes we can approve CAPWAP via email 18:14:12 #info phrobb has sent mail about timezones for TSC meetings 18:14:58 #info phrobb is still working on intern stuff 18:15:22 #info Need to propose intern projects, people are asking for them 18:16:04 #info phrobb notes that job board will go live next week, good for posting inter positions, phrobb will add link next week 18:16:08 colindixon: projects ? 18:16:14 colindixon: on the main page that don't exist 18:16:19 colindixon: approved etc 18:16:32 #topic updates 18:17:10 #info Apparently there are projects listed on ODL wikis that were never approved 18:17:25 #action phrobb will help to clean up the non-projects from the wiki 18:17:43 #action colindixon will try to explore the use categories which allow for easier curation of this 18:17:55 edwarnicke: FYI you're really... scratchy / broken 18:18:14 #info Everyone, please watch the wiki for mistakes like this 18:18:43 #info Call for papers for Summit comes out next week 18:18:56 dfarrell07 is fast and good at things 18:19:21 #action phrobb will get an email thread going on when we want to do a face-to-face 18:19:28 #undo 18:19:28 Removing item from minutes: 18:19:30 colindixon: Thanks :) 18:19:30 #action phrobb to start an e-mail thread on when to do a when to do a face-to-face meeting, initial ideas is 4/14-4/15 18:20:08 #info Chris Wright 18:20:44 #info zxiiro got the Lithium autobuild works and he has a simpler version he wants to propose 18:21:16 #info zxiiro will send email about Li autobuild to describe what he did 18:21:30 #info M1 for offset 0 is today 18:21:56 #info Do all the required things, projects that are offset 0 18:22:25 #info No committer promotions today 18:22:33 #topic Project Creation Reviews 18:23:00 * dfarrell07 would love help from projects under review to take these notes 18:23:11 #undo 18:23:11 Removing item from minutes: 18:23:22 #topic Unified Secure Channel Creation Review 18:23:42 #link https://wiki.opendaylight.org/view/Project_Proposals:USC the project proposal page 18:24:10 #link https://lists.opendaylight.org/pipermail/project-proposals/2014-November/000203.html it was proposed on 11/20/2014 18:24:39 #link https://wiki.opendaylight.org/view/File:Odl-usc-2014_11_20.pdf <— slide deck "very close" to what is being currently presented 18:24:50 #info jmedved 18:24:57 phrobb: thanks 18:25:07 * dfarrell07 doesn't have video, mobile is failing for some reason, hard to follow and take notes 18:26:16 * ChrisPriceAB I just love the sequence diagrams in this proposal! 18:26:54 * edwarnicke <3 sequence diagrams ;) 18:27:21 dfarrell07: undertood 18:27:50 #info the general idea is to provide a secure channel (or tunnel) between a device and the controller as well as a way to “call home” 18:28:16 #info the idea is to do it in a way that is independent of the control protocol rather than each protocol having it’s own security 18:29:47 #info they can also tunnel multiple protocols in a single “channel” effectively sharing a single security model across them 18:30:21 So - just wanted to check this is not cover the OpenFlow 18:30:41 #info the intent is to provide three main components: USC manager, USC plugin, and a USC agent 18:31:26 idk your nic, but nice, quick presentation 18:31:37 * ChrisPriceAB indeed 18:32:05 What is the secure channel tunnel protocol? 18:33:05 Isn't this a bit of an overlap witht he SNBI project? 18:33:06 +1 to edwarnicke's question 18:33:08 VOIP is breaking up very badly for me 18:33:27 #info abhijitkumbhare asks if they want to apply this to OpenFlow’s secure channel 18:33:59 #Info Helen responds saying that it’s not in scope at the moment, but they might try to support that in the future 18:34:04 kwatsen: I’m hearing everything fine 18:34:22 it's cleared up now, thanks 18:34:48 #info edwarnicke (and rexpugh on IRC) ask what the underlying protocol for the secure channel is 18:36:26 #info Answer: multiple underlying protocols for secure channel 18:36:39 #info they will start with ssh as the underlying part 18:37:50 #info kwatsen says that what NETCONF does is just use ssh, it works for only TCP connections, but works for all TCP connections 18:38:11 #info later they will look into more general solutions as well in the future 18:40:14 #info kwatsen offers to work with the team on the approach to solving this, he seems to be an expert in the area (he mentions IETF call-home standards) 18:41:14 #info LuisGomez points out that "Control Channel" or "Management Channel" might should be in the title or description 18:41:18 #info LuisGomez asks if this is going to be used for management and control traffic only and if this could be added it might make things clearer 18:42:23 #info Presenter points out that they might want to make it more general in the future, so "Control Channel" or "Management Channel" might not make as much sense in the future 18:42:41 #info colindixon asks, and Helen confirms that this is intended to be *one* thing you could use, not *the* solution that all people should/must use 18:43:18 #info LuisGomez clarifies that his worry is that the name USC might be overly broad, but doesn’t seem to strenuously object 18:43:37 #info Helen says their intent is to make it as broad as possible and so the name fits 18:43:38 #info LuisGomez seems to move to consensus with Helen that name is okay 18:44:34 missing UID for Jinzhu Duan... 18:45:06 idk syntax for vote 18:45:20 is there a doc/spec for the protocol being talked about? 18:45:24 I'll do the vote dfarrell07 18:45:24 I will take care Duanjingzhu's username 18:45:33 dfarrell07: it's #vote ? option, option, option 18:45:46 #action gzhao will find username of Duanjingzhu 18:45:48 #action gzhao will fill in the Duan Jingzhu’s username 18:45:48 dfarrell07: the ? is required as is the comma between options 18:45:56 dfarrell07: and it's actually #startvote 18:46:13 looks like %startvote Shall the TSC approve the Internet of Things Data Management (IOTDM) project to Incubation? -1, 0, +1 18:46:19 but with a pound 18:46:41 how does this project compliment the SNBi Project? 18:46:44 ChrisPriceAB, tykeal: Awesome, thanks for education :) 18:46:52 dfarrell07: sure thing 18:46:52 dfarrell07: do you have it? 18:46:55 May be we should allow a 10 day grace period to add committers after a TSC approval of a project 18:47:09 I have it 18:47:29 #info rexpugh asks what the overlap is with SNBi 18:47:41 dfarrell07: thanks, I’ll say when :-) 18:47:47 colindixon: ACK 18:48:23 #Info Helen responds that she originally thought there was significant overlap, but after talking to Franke she thinks much less so at least in the short run 18:48:35 #info SNBi is focused on L2 inside the data center building trust hop-by-hop 18:49:03 #info USC is focused on longer-distance communication through tunnels 18:49:13 #info in the future they two might merge, but for now they’re very different 18:49:34 #startvote Shall the TSC approve Unified Secure Channel project to Incubation? -1, 0, +1 18:49:34 Begin voting on: Shall the TSC approve Unified Secure Channel project to Incubation? Valid vote options are -1, 0, +1. 18:49:34 Vote using '#vote OPTION'. Only your last vote counts. 18:49:41 #vote +1 18:49:43 #vote +1 18:49:44 #vote +1 18:49:49 #vote +1 18:49:50 #vote +1 18:49:51 #vote +1 18:49:58 #vote +1 18:50:02 #vote +1 18:50:03 #vote +1 18:50:06 +1 18:50:08 #vote +1 18:50:20 I think that's all, right? 18:50:21 #vote +1 18:50:25 #endvote 18:50:25 Voted on "Shall the TSC approve Unified Secure Channel project to Incubation?" Results are 18:50:25 +1 (11): dlenrow, jmedved, LuisGomez, edwarnicke, ChrisPriceAB, cdub, mohnish, kwatsen, colindixon, Youcef, RajeevK 18:50:26 Welcome Rajeev to TSC 18:50:28 * ChrisPriceAB welcome RajeevK 18:50:42 Welcome Rajeev 18:50:45 #agreed USC has been moved to Incubation 18:50:48 #agreed the USC project is moved to incubation 18:50:49 Welcome RajeevK :) 18:50:52 #undo 18:50:52 Removing item from minutes: 18:50:59 welcome RajeevK 18:51:00 #topic welcome Rajeev as the rep from Intel 18:51:06 #info the TSC welcomes RajeevK from Intel :) 18:51:23 welcome RajeevK 18:51:48 Need 8 to pass 18:51:51 Thanks everyone! Good to be here. Look forward to working with you all :) 18:52:17 welcome rajeevk, looking forward to working with you 18:52:49 I only count 11 platinum members 18:52:55 #info colindixon has updated Project Proposal main page with before/after HOWTO info 18:53:14 gzhao: +2 at-large members :) 18:53:19 #topic LACP Creation Review 18:53:54 edwarnicke: I see. 18:53:55 So total TSC is 13 18:54:10 #link https://wiki.opendaylight.org/view/Project_Proposals:Link_Aggregation_Control_Protocol the project proposal 18:54:12 then 7 to pass 18:54:26 #link https://wiki.opendaylight.org/view/File:LACP_Proposal.pptx the presentation 18:54:43 #link https://lists.opendaylight.org/pipermail/project-proposals/2014-October/000184.html the project was proposed on 10/22/2014 18:55:32 #info LACP is an IEEE spec that defines a protocol to bundle multiple switch links into a single logical interface providing link redundancy and bandwidth aggregation 18:56:25 Its IEEE 802.3ad 18:57:05 #info the spec is IEEE 803.2ad (thanks mohnish) 18:57:16 mohnish: you can do #info statements even not as a meeting chair 18:57:30 colin: sure 18:57:59 the #info and #link are available to everyone :-) 18:58:07 using IRC to take notes is very, very nice 18:58:48 #info the general idea it to implement the LACP protocol with its various state machines (there seem to be 6 state machines) 18:59:16 #Info current plan is to speak LACP via packet_in/packet_out using the OpenFlow plugin 18:59:57 #info this implementation is focused on LACP with switches/servers that are externals to SDN network 19:00:15 mohnish: I was going to ask that 19:00:35 I assume the implication is that you can just direction configure that within the SDN-controlled part 19:00:56 #info they are defining 5 yang files that govern the protocol and implementation 19:01:03 internal to SDN network, SDN controller can take care of using various existing techniques and flow mods 19:01:15 mohnish: that makes sense 19:02:16 #info they describe various ways to implement LACP-equivalents with OpenFlow internally to the SDN fabric. e.g., using group table entries of type “select" 19:03:01 mohnish: is the idea that the LACP driver will actually rewrite packet_ins as they come in through the OF plugin? 19:03:11 if so, does it need to work with the OF plugin? 19:03:19 #info we are trying to preserve existing ODL apps behavior with respect to port or logical port 19:03:56 yes, it requires work on OF plugin 19:04:06 ok 19:04:10 abhijitkumbhare: thoughts? 19:04:48 #info the project would like to translate physical ports in OpenFlow to logical ports so that most SDN applications need not know about the LACP to take advantage of it 19:05:23 #info this would need to not apply to LACP and LLDP messages, because those need to know about physical ports 19:05:49 Sorry folks - I had to take a call last 5-10 minutes - 19:06:15 abhijitkumbhare: while you were go we decided to rewrite the OF plugin in Lua :p 19:06:27 colindixon: roflmao 19:06:31 Haha 19:06:31 colin: I spoke to Abhijit and he is aware of the requirement 19:06:33 hahaha 19:06:39 mohnish: cool 19:06:47 I had a meeting with Mohnish & folks yesterday regarding this 19:07:05 would be good just to get that spoken outloud at some point 19:07:16 OK 19:07:34 ok 19:07:43 it seems like we could rewrite to a logical port, but provide another piece of data to give the original physical port for apps that care 19:07:47 e.g., LLDP 19:08:49 yes... OF plugin can parse the packet in to figure out when to substitute 19:09:42 #info port's transition to participate in LAG requires state changes in L2switch modules 19:10:14 #Info there is a long discussion in the slides about the implications of translating physical port to the logical (bonded) port and how that impacts other apps, e.g., the L2 Switch 19:11:53 Is this OpenFlow specific? Why not implement as a LAG logic that can sit above any uni-link SBI? 19:12:26 dlenrow: my guess is that there will be a an OF-independent layer and the an OF-specific implementation 19:12:36 Aren't their non-OF uni-link SBIs that will want LAG/Bonding in controller platform? 19:13:42 dlenrow: among other things, they will *have* use the FlowProgramming interfaces, which are only partly tied to OpenFlow 19:14:50 #info colindixon asks is if it’s OF-specific on behalf of dlenrow 19:15:16 #info the response is that it’s mostly OF-Independent except for getting packet_in/packet_out 19:15:39 #info response is also that it’s just using the MD-SAL FlowProgramming concepts even for the OF-specific parts 19:15:51 tykeal: Are the email addresses given in committer list enough for you, or do you need username of gerrit et al. https://wiki.opendaylight.org/view/Project_Proposals:Link_Aggregation_Control_Protocol 19:16:04 Fair enough, until we can think of another SBI that this could apply to, it's a non-issue. 19:16:24 dlenrow: That said... I think one can think a bit around doing it in a way that eases the path when we get there :) 19:16:32 #info LuisGomez says likes the proposal because (1) the use case is clear and (2) it’s looks carefully at impacts on other projects 19:16:34 dfarrell07: finding accounts based on email addresses has a 25 - 50% rate of failure for me 19:16:54 it's why I keep asking for everyone to put their UID in the proposals 19:17:09 #info LuisGomez asks if they intent to support Multi-chassis LAG, the answer is maybe in the future 19:17:14 #info tykeal asks (as always) that the committers list include UIDs 19:17:50 thank you! 19:17:55 #action mohnish will get the remaining User IDs for the project 19:17:59 Would it be possible to get someone to do a mechanical screen of project proposals for things like the ODL user ids before they come to review? 19:18:07 (not review for content, just mechanics) 19:18:16 edwarnicke: phrobb and I try to 19:18:23 #startvote Shall the TSC approve LACP project to Incubation? -1, 0, +1 19:18:23 Begin voting on: Shall the TSC approve LACP project to Incubation? Valid vote options are -1, 0, +1. 19:18:23 Vote using '#vote OPTION'. Only your last vote counts. 19:18:25 colindixon: Cool :) 19:18:28 #vote +1 19:18:29 #vote +1 19:18:30 #vote +1 19:18:32 #vote +1 19:18:32 #vote +1 19:18:36 #vote +1 19:18:38 #vote +1 19:18:40 #vote +1 19:18:48 8/13 19:18:53 #endvote 19:18:53 Voted on "Shall the TSC approve LACP project to Incubation?" Results are 19:18:53 +1 (8): dlenrow, jmedved, LuisGomez, edwarnicke, ChrisPriceAB, mohnish, colindixon, RajeevK 19:19:00 #agreed The TSC votes to move the LACP project to incubation 19:19:19 thanks 19:19:29 * ChrisPriceAB congrats 19:19:32 congrats LACP :) 19:19:56 Congrats LACP :) 19:19:58 #topic Time Series Data Repository Creation Review 19:20:03 dfarrell07: thanks! 19:20:44 #link https://wiki.opendaylight.org/view/Project_Proposals:Time_Series_Data_Repository the project proposal 19:20:54 #link https://wiki.opendaylight.org/view/File:TSDR_Proposal_ODL.pptx the slides 19:21:14 #link https://lists.opendaylight.org/pipermail/project-proposals/2014-November/000193.html the proposal happened on 11/7/2014 19:22:14 #info Time Series Data Repository (TSDR) is trying to capture things that might be time-varying values for the same “keys”, e.g., stats counters, performance data, health status, etc. 19:22:31 #info for Lithium the focus is on OF stats 19:22:45 Interesting 19:23:36 if done right, this is *hugely* helpful 19:23:58 #info major functions are data collection, storage, queries, aggregation and purge 19:24:00 time series data is the main focus here ... actual contents are secondary. So we picked the OF stats as the starting point. 19:24:07 agreed, very interesting. wondering how this would relate or be a ODL implementation of something like http://opentsdb.net/ 19:24:51 #info mohnish notes that the time series is the focus here, but the OF stats are the first logical thing to apply it to 19:25:36 dbainbri: good Q 19:26:03 * ChrisPriceAB apologies TSC I need to drop off the call now... 19:26:44 #info ChrisPriceAB has to leave the call, abhijitkumhare will take my vote on coming actions. 19:26:46 it is using HBASE as well, which is exactly what opentsdb uses 19:26:50 dbainbri: thought process is inline with TSDB 19:27:20 * ChrisPriceAB thanks abhijit 19:27:45 #info dbainbri asks if this could be done with OpenTSDB ( http://opentsdb.net/ ) 19:27:46 mohnish: why not reuse the implementation. have a TSDR interface and have that implemented use openTSDB as opposed to reimplement a customer openTSDB implementation? 19:28:08 No problems ChrisPriceAB 19:28:22 #info mohnish says that their ideas are inline with that (e.g., they both use HBase on the back end) 19:29:00 * cdub has to leave 19:29:03 dbainbri: focus of this proposal is extracting time series data out of ODL and export it out ..... export can be anything TSDB or something else. 19:29:19 #info the approach is to have the TSDR service track certain places in the MD-SAL and copy that data (with it’s historical values) in a parallel data store (maybe a parallel MD-SAL data store instance) 19:29:40 #info dfarrell07 will take over for cdub for Red Hat's vote 19:29:41 mohnish: but also query the data back through MD-SAL? or only export? 19:29:45 colindixon: dfarrell07 is my delegate 19:29:51 cdub: thanks! 19:30:21 dfarrell07 is a formidable delegate 19:30:27 colindixon: ;) 19:30:38 dbainbri: we want to extend the functionality to ODL apps having the ability to query some useful info our of the TSDR 19:31:04 out of TSDR ... 19:31:08 any changes (Additions) to the GUI (DLUX) to be added as part of this visualizations of TSDR 19:31:21 #info the goal is that the TSDR could use multiple backing stores, e.g., HBase and Splunk 19:31:48 dbainbri: we didn't kept it in the scope ... but we can do it as futures 19:32:20 generic question we are struggling with internally. when does a controller become a network management system ;) 19:33:02 dbainbri: yes that is a good one. esp. what precisely is the distinguishing property? ;) 19:33:11 #info dbainbri asks about how this would be integrated into existing ODL apps, can it be accessed from the MD-SAL? is it intended to be added to the existing apps, e.g., the DLUX GUI 19:33:33 dbainbri, rovarga: about 6 months ago in ODL? maybe longer? :p 19:33:48 lol 19:33:59 intention here is extract the time series data for some external entity to make sense out of it ..... and if any ODL app wants to use the time series (aggregated ) data for its usecase, then it is available as well 19:34:01 #info mohnish says that this isn’t in the scope yet, but it could be done later? 19:34:35 is there q requirement that all data in the TSDR be internally consistent? ie. if i have metrics for a node in TSDR, but the node is deleted, what happens to the metrics? 19:34:48 mohnish and YuLing, is the idea to have parallel APIs to the MD-SAL or to work to extend the MD-SAL so that you can ask for old data? 19:35:00 I get the feeling it’s parallel APIs using the same keys 19:35:41 colin: it is still in discussions with Jan Medved and others. 19:36:28 #info colindixon asks if this will be via parallel APIs to the MD-SAL or be extensions to the existing APis in the MD-SAL 19:36:47 #info mohnish responds that he, jmedved and other are still discussing this 19:36:49 would be valuable to extend the function capabilities beyond min. max, avg w/o having to recompile code. perhaps a way to register functions that proxy to the implementation in the TSDR backing store implementation 19:36:59 dbainbri: if the node is deleted, it is upto the data storage service in ODL to either drop those tables or continue to keep it. Depends on the usecase 19:37:27 #info dfarrell07 thinks this would be useful for his work on ODL Perf and Tools sub-team of Integration team 19:37:48 what is the granularity for the TS data, for example, last time i looked at openTSDB the granularity was to 1 second, but not sub-second 19:38:07 do we see TSDR specifying this? 19:38:25 colin: little bit more insight. There are APIs to TSDR and these are new. But how to collect data, depends on using the MDSAL APIs. 19:38:51 #info the plan is persist all the TSDR data and provide queries to get metrics from the recorded data 19:39:40 #info mohnish adds (on the parallel vs. extended APIs) that the APis to access the TSDR will be new (and thus likely parallel to the MD-SAL) 19:39:47 I would let Yuling to answer on granularity ... she has the prototype 19:41:14 while i think this is a much needed project, it does add to the complexity of a deployment and operation of an ODL system. HBASE implies several hosts and processes to support HA and a repliable store 19:42:04 #info dbainbri asks about the granularity of the time data, e.g., OpenTSDB was only at second granularities 19:44:49 Is TSDR relying on the newly proposed persistence project for the persistence API implementation? 19:44:52 #info the response is that the goal is provide something can receive events at the subsecond (e.g., millisecond time granularity will be accepted), but the goal for use cases is providing data back on the order minutes 19:45:33 I believe AAA, TSDR and AADS are consumers of the persistence project object store API's and DAO's? 19:45:37 #info jmedved, dbainbri, mohnish, and others talk about how performant it will be and/or needs to be 19:45:37 rex; we are working with Mark on the persistance API. Intending to leverage it. 19:46:13 #info rexpugh asks if TSDR will use the persistence project’s APIs, the response is yes they’re working with mark to consume those APIs 19:46:15 Thanks mohnish, you and i knew that but i wanted to make sure the community knows it ;) 19:46:29 rex: :-) 19:48:09 #info dbainbri notes that adding things like HBase drastically increases the difficult to deploy the controller as it adds more nodes and servers that need to be deployed 19:48:47 #Info mohnish says that this has come up before and the goal is to package *something* that “works” out of the box, but can be scaled out to multiple hosts and process if need be 19:49:22 #info dbainbri, edwarnicke say that the TSC may want to figure out deployment models and how we keep things to be both easy to deploy quickly and run across multiple nodes 19:49:54 I have vote 19:49:56 #startvote Shall the TSC approve the TSDR project to incubation? +1, 0, -1 19:49:56 Begin voting on: Shall the TSC approve the TSDR project to incubation? Valid vote options are +1, 0, -1. 19:49:56 Vote using '#vote OPTION'. Only your last vote counts. 19:50:02 nvm, lol 19:50:02 #vote +1 19:50:03 #vote +1 19:50:03 #vote +1 19:50:06 #vote +1 19:50:07 #vote +1 19:50:08 #vote +1 19:50:09 #vote +1 19:50:10 #vote +1 19:50:10 #vote +1 19:50:13 #vote +1 19:50:15 #vote +1 19:50:26 many/13 19:50:29 #endvote 19:50:29 Voted on "Shall the TSC approve the TSDR project to incubation?" Results are 19:50:29 +1 (11): dlenrow, jmedved, LuisGomez, dfarrell07, edwarnicke, RajeevK, mohnish, kwatsen, colindixon, abhijitkumbhare, Youcef 19:50:38 dfarrell07: you win the call 19:50:49 thanks 19:50:49 #agreed TSC approves TSDR to Incubation 19:51:28 * tykeal notes missing ODL UIDs again... 19:51:39 * tykeal sighs 19:51:41 tykeal: Never stop noting that ;) 19:51:46 #info TSDR needs up update wiki with UIDs of committers 19:51:51 #action TSDR needs up update wiki with UIDs of committers 19:51:54 #undo 19:51:54 Removing item from minutes: 19:52:08 #action mohnish needs up update wiki with UIDs of committers 19:52:15 dfarrell07: thanks 19:52:17 #undo 19:52:17 Removing item from minutes: 19:52:32 #action mohnish needs to update TSDR wiki with UIDs of committers 19:52:43 *finally got it right* 19:53:02 #info colindixon notes that TSC calls often bubble up issues that are cross-project in nature. He asks "should a Project Lead be at least following the TSC list and reading the TSC minutes.. and hopefully that the Project Leads attend TSC meetings as often as possible" 19:53:10 I would like to discuss some project creation process issues if we have a spare minute today 19:53:12 #undo 19:53:12 Removing item from minutes: 19:53:13 #topic using the TSC meeting as a cross-project coordination 19:53:19 #info colindixon notes that TSC calls often bubble up issues that are cross-project in nature. He asks "should a Project Lead be at least following the TSC list and reading the TSC minutes.. and hopefully that the Project Leads attend TSC meetings as often as possible" 19:53:32 colin: can we take up the AD-SAL discussion ? I am going to be offline for the next four weeks. Unless someone else can take it up in the next meeting.... 19:54:34 #action colindixon will send mail about encouraging projects to get projects tracking what happens in the TSC 19:54:47 #topic supporting the AD-SAL 19:55:07 #info rgowrishankar points out that we’re having lots of problems with supporting the AD-SAL in Helium 19:55:17 #info this seems to be causing a lot of confusion among ODL users 19:55:36 +1 to user confusion (as a major contributor to ask.odl) 19:56:39 #info the question is (i) can we deprecate the AD-SAL and compatibility layer, (ii) if not who will maintain it, (iii) how do we convey the level of support (or lack thereof) to users 19:57:32 does the mix of AD-SAL and MD-SAL conflict with the singularity policy? 19:58:08 kwatsen: not until the project is core, and it’s the same project 19:58:21 which means I have no idea how singularity would apply 19:58:32 #info colindixon asks edwarnicke if the AD-SAL is going to be deprecated in Lithium 19:59:18 #info edwarnicke responds saying nobody is maintaining the AD-SAL and hasn’t been for a while, he fixed bugs at the end of Helium, but doesn’t want to keep doing things 19:59:28