17:59:54 <colindixon> #startmeeting tsc
17:59:54 <odl_meetbot> 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 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:59:54 <odl_meetbot> The meeting name has been set to 'tsc'
18:00:04 <colindixon> #topic roll call and agenda bashing
18:00:08 <colindixon> #info colindixon
18:00:23 <colindixon> #link https://wiki.opendaylight.org/view/TSC:Main the agenda in it’s usual place
18:00:33 <dlenrow> #info dlenrow
18:01:16 <phrobb> feel free to chair me Colin
18:02:17 <edwarnicke> #info edwarnicke
18:02:27 <kwatsen> #info kwatsen
18:02:29 <colindixon> #chair phrobb
18:02:29 <odl_meetbot> Current chairs: colindixon phrobb
18:03:01 <tykeal> hand it to dfarrell07? he does good scribe as well ;)
18:03:08 <dfarrell07> I can do some
18:03:20 <colindixon> #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 <dfarrell07> no hope of being as good as tbachman ;)
18:03:24 <phrobb> #chair dfarrell07
18:03:24 <odl_meetbot> Current chairs: colindixon dfarrell07 phrobb
18:03:24 <colindixon> #chair dfarrell07
18:03:24 <odl_meetbot> Current chairs: colindixon dfarrell07 phrobb
18:03:35 <LuisGomez> #info LuisGomez
18:03:36 * edwarnicke is pretty sure the rest of us are optional but tbachman is mandatory...
18:03:43 <colindixon> #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 <Youcef> #info Youcef Laribi
18:04:43 <colindixon> #action colindixon to start the conversation and collect ideas on how to resolve cross-project version bumping in timely fashion
18:04:43 <colindixon> #undo
18:04:43 <colindixon> #action colindixon zxiiro mlemay and edwarnicke to work on better version management and version bumping and present it here
18:04:43 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Action object at 0x2695c10>
18:04:55 <tykeal> colindixon: we can't hear you
18:05:53 <LuisGomez> colindixon, we cannot hear you
18:06:10 <alagalah> Howdy y'all
18:06:29 <dfarrell07> He's on IRC mlemay
18:07:17 <mlemay> hey
18:07:22 <mlemay> I'm here
18:07:30 <dfarrell07> mlemay: They were asking about version bump
18:07:43 <mohnish> #info mohnish
18:07:44 <mlemay> ahhh yea can't join in voice.. but I'm here
18:07:47 <dfarrell07> #info Discussion about version bumping better with zxiiro mlemay and edwarnicke
18:08:08 <ChrisPriceAB> #info Chris Price (apologies I'm late)
18:08:11 <regXboi> 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 <regXboi> #info regXboi - here to apologize for not being here - and then running away
18:08:49 <dfarrell07> #info phrobb working with tykeal to get new certs for OSX, progress but no solution yet
18:09:04 <mlemay> about version bumping .. there is version of multiple things
18:09:16 <mlemay> (features vs bundles) mainly
18:09:31 <edwarnicke> mlemay: Have you looked at yangtools-artifacts, mdsal-artifacts, etc
18:09:53 <mlemay> 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 <dfarrell07> #info phrobb worked with CAPWAP to revise project proposal
18:10:00 <edwarnicke> 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 <edwarnicke> mlemay: I've hit that as I'm trying to use them
18:10:21 <colindixon> #action edwarnicke and jan medved to work with phrobb to the mac certificate issue
18:10:22 * colindixon is back
18:10:44 <edwarnicke> colindixon: I was only kidding about us not being able to run a TSC call without tbachman ?
18:10:53 <colindixon> edwarnicke: :-)
18:11:14 <regXboi> 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 <regXboi> bye all
18:11:51 <dfarrell07> regXboi: bye :)
18:12:59 <dfarrell07> Am I right that the agenda hasn't been updated? https://wiki.opendaylight.org/view/TSC:Main
18:13:25 <mlemay> @edwarnicke: I did look into the artifacts (we are talking about yangtools/commons/artifacts) right?
18:13:34 <mlemay> saw and looked at the git reviews
18:13:49 <dfarrell07> #info colindixon hopes we can approve CAPWAP via email
18:14:12 <dfarrell07> #info phrobb has sent mail about timezones for TSC meetings
18:14:58 <dfarrell07> #info phrobb is still working on intern stuff
18:15:22 <dfarrell07> #info Need to propose intern projects, people are asking for them
18:16:04 <dfarrell07> #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 <alagalah> colindixon: projects ?
18:16:14 <alagalah> colindixon: on the main page that don't exist
18:16:19 <alagalah> colindixon: approved etc
18:16:32 <colindixon> #topic updates
18:17:10 <dfarrell07> #info Apparently there are projects listed on ODL wikis that were never approved
18:17:25 <colindixon> #action phrobb will help to clean up the non-projects from the wiki
18:17:43 <colindixon> #action colindixon will try to explore the use categories which allow for easier curation of this
18:17:55 <tykeal> edwarnicke: FYI you're really... scratchy / broken
18:18:14 <dfarrell07> #info Everyone, please watch the wiki for mistakes like this
18:18:43 <dfarrell07> #info Call for papers for Summit comes out next week
18:18:56 <colindixon> dfarrell07  is fast and good at things
18:19:21 <dfarrell07> #action phrobb will get an email thread going on when we want to do a face-to-face
18:19:28 <colindixon> #undo
18:19:28 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Action object at 0x2728950>
18:19:30 <dfarrell07> colindixon: Thanks :)
18:19:30 <colindixon> #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 <cdub> #info Chris Wright
18:20:44 <colindixon> #info zxiiro got the Lithium autobuild works and he has a simpler version he wants to propose
18:21:16 <dfarrell07> #info zxiiro will send email about Li autobuild to describe what he did
18:21:30 <dfarrell07> #info M1 for offset 0 is today
18:21:56 <dfarrell07> #info Do all the required things, projects that are offset 0
18:22:25 <dfarrell07> #info No committer promotions today
18:22:33 <dfarrell07> #topic Project Creation Reviews
18:23:00 * dfarrell07 would love help from projects under review to take these notes
18:23:11 <colindixon> #undo
18:23:11 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x2728410>
18:23:22 <colindixon> #topic Unified Secure Channel Creation Review
18:23:42 <colindixon> #link https://wiki.opendaylight.org/view/Project_Proposals:USC the project proposal page
18:24:10 <colindixon> #link https://lists.opendaylight.org/pipermail/project-proposals/2014-November/000203.html it was proposed on 11/20/2014
18:24:39 <phrobb> #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 <jmedved> #info jmedved
18:24:57 <colindixon> 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 <colindixon> dfarrell07: undertood
18:27:50 <colindixon> #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 <colindixon> #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 <colindixon> #info they can also tunnel multiple protocols in a single “channel” effectively sharing a single security model across them
18:30:21 <abhijitkumbhare> So - just wanted to check this is not cover the OpenFlow
18:30:41 <colindixon> #info the intent is to provide three main components: USC manager, USC plugin, and a USC agent
18:31:26 <dfarrell07> idk your nic, but nice, quick presentation <person>
18:31:37 * ChrisPriceAB indeed
18:32:05 <rexpugh> What is the secure channel tunnel protocol?
18:33:05 <rexpugh> Isn't this a bit of an overlap witht he SNBI project?
18:33:06 <abhijitkumbhare> +1 to edwarnicke's question
18:33:08 <kwatsen> VOIP is breaking up very badly for me
18:33:27 <colindixon> #info abhijitkumbhare asks if they want to apply this to OpenFlow’s secure channel
18:33:59 <colindixon> #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 <colindixon> kwatsen: I’m hearing everything fine
18:34:22 <kwatsen> it's cleared up now, thanks
18:34:48 <colindixon> #info edwarnicke (and rexpugh on IRC) ask what the underlying protocol for the secure channel is
18:36:26 <dfarrell07> #info Answer: multiple underlying protocols for secure channel
18:36:39 <colindixon> #info they will start with ssh as the underlying part
18:37:50 <colindixon> #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 <colindixon> #info later they will look into more general solutions as well in the future
18:40:14 <colindixon> #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 <dfarrell07> #info LuisGomez points out that "Control Channel" or "Management Channel" might should be in the title or description
18:41:18 <colindixon> #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 <dfarrell07> #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 <colindixon> #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 <colindixon> #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 <colindixon> #info Helen says their intent is to make it as broad as possible and so the name fits
18:43:38 <dfarrell07> #info LuisGomez seems to move to consensus with Helen that name is okay
18:44:34 <tykeal> missing UID for Jinzhu Duan...
18:45:06 <dfarrell07> idk syntax for vote
18:45:20 <RajeevK> is there a doc/spec for the protocol being talked about?
18:45:24 <phrobb> I'll do the vote dfarrell07
18:45:24 <gzhao> I will take care Duanjingzhu's username
18:45:33 <tykeal> dfarrell07: it's #vote <vote question>? option, option, option
18:45:46 <dfarrell07> #action gzhao will find username of Duanjingzhu
18:45:48 <colindixon> #action gzhao will fill in the Duan Jingzhu’s username
18:45:48 <tykeal> dfarrell07: the ? is required as is the comma between options
18:45:56 <tykeal> dfarrell07: and it's actually #startvote
18:46:13 <ChrisPriceAB> looks like %startvote Shall the TSC approve the Internet of Things Data Management (IOTDM) project to Incubation? -1, 0, +1
18:46:19 <ChrisPriceAB> but with a pound
18:46:41 <rexpugh> how does this project compliment the SNBi Project?
18:46:44 <dfarrell07> ChrisPriceAB, tykeal: Awesome, thanks for education :)
18:46:52 <tykeal> dfarrell07: sure thing
18:46:52 <colindixon> dfarrell07: do you have it?
18:46:55 <abhijitkumbhare> May be we should allow a 10 day grace period to add committers after a TSC approval of a project
18:47:09 <dfarrell07> I have it
18:47:29 <colindixon> #info rexpugh asks what the overlap is with SNBi
18:47:41 <colindixon> dfarrell07: thanks, I’ll say when :-)
18:47:47 <dfarrell07> colindixon: ACK
18:48:23 <colindixon> #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 <colindixon> #info SNBi is focused on L2 inside the data center building trust hop-by-hop
18:49:03 <colindixon> #info USC is focused on longer-distance communication through tunnels
18:49:13 <colindixon> #info in the future they two might merge, but for now they’re very different
18:49:34 <dfarrell07> #startvote Shall the TSC approve Unified Secure Channel project to Incubation? -1, 0, +1
18:49:34 <odl_meetbot> Begin voting on: Shall the TSC approve Unified Secure Channel project to Incubation? Valid vote options are -1, 0, +1.
18:49:34 <odl_meetbot> Vote using '#vote OPTION'. Only your last vote counts.
18:49:41 <colindixon> #vote +1
18:49:43 <cdub> #vote +1
18:49:44 <kwatsen> #vote +1
18:49:49 <LuisGomez> #vote +1
18:49:50 <mohnish> #vote +1
18:49:51 <Youcef> #vote +1
18:49:58 <dlenrow> #vote +1
18:50:02 <edwarnicke> #vote +1
18:50:03 <jmedved> #vote +1
18:50:06 <RajeevK> +1
18:50:08 <ChrisPriceAB> #vote +1
18:50:20 <dfarrell07> I think that's all, right?
18:50:21 <RajeevK> #vote +1
18:50:25 <dfarrell07> #endvote
18:50:25 <odl_meetbot> Voted on "Shall the TSC approve Unified Secure Channel project to Incubation?" Results are
18:50:25 <odl_meetbot> +1 (11): dlenrow, jmedved, LuisGomez, edwarnicke, ChrisPriceAB, cdub, mohnish, kwatsen, colindixon, Youcef, RajeevK
18:50:26 <dlenrow> Welcome Rajeev to TSC
18:50:28 * ChrisPriceAB welcome RajeevK
18:50:42 <mohnish> Welcome Rajeev
18:50:45 <dfarrell07> #agreed USC has been moved to Incubation
18:50:48 <colindixon> #agreed the USC project is moved to incubation
18:50:49 <edwarnicke> Welcome RajeevK :)
18:50:52 <colindixon> #undo
18:50:52 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Agreed object at 0x2844490>
18:50:59 <LuisGomez> welcome RajeevK
18:51:00 <colindixon> #topic welcome Rajeev as the rep from Intel
18:51:06 <dfarrell07> #info the TSC welcomes RajeevK from Intel :)
18:51:23 <kwatsen> welcome RajeevK
18:51:48 <dlenrow> Need 8 to pass
18:51:51 <RajeevK> Thanks everyone! Good to be here. Look forward to working with you all :)
18:52:17 <jmedved> welcome rajeevk, looking forward to working with you
18:52:49 <gzhao> I only count 11 platinum members
18:52:55 <dfarrell07> #info colindixon has updated Project Proposal main page with before/after HOWTO info
18:53:14 <edwarnicke> gzhao: +2 at-large members :)
18:53:19 <phrobb> #topic LACP Creation Review
18:53:54 <gzhao> edwarnicke: I see.
18:53:55 <phrobb> So total TSC is 13
18:54:10 <colindixon> #link https://wiki.opendaylight.org/view/Project_Proposals:Link_Aggregation_Control_Protocol the project proposal
18:54:12 <gzhao> then 7 to pass
18:54:26 <colindixon> #link https://wiki.opendaylight.org/view/File:LACP_Proposal.pptx the presentation
18:54:43 <colindixon> #link https://lists.opendaylight.org/pipermail/project-proposals/2014-October/000184.html the project was proposed on 10/22/2014
18:55:32 <colindixon> #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 <mohnish> Its IEEE 802.3ad
18:57:05 <colindixon> #info the spec is IEEE 803.2ad (thanks mohnish)
18:57:16 <colindixon> mohnish: you can do #info statements even not as a meeting chair
18:57:30 <mohnish> colin: sure
18:57:59 <colindixon> the #info and #link are available to everyone :-)
18:58:07 <colindixon> using IRC to take notes is very, very nice
18:58:48 <colindixon> #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 <colindixon> #Info current plan is to speak LACP via packet_in/packet_out using the OpenFlow plugin
18:59:57 <mohnish> #info this implementation is focused on LACP with switches/servers that are externals to SDN network
19:00:15 <colindixon> mohnish: I was going to ask that
19:00:35 <colindixon> I assume the implication is that you can just direction configure that within the SDN-controlled part
19:00:56 <colindixon> #info they are defining 5 yang files that govern the protocol and implementation
19:01:03 <mohnish> internal to SDN network, SDN controller can take care of using various existing techniques and flow mods
19:01:15 <colindixon> mohnish: that makes sense
19:02:16 <colindixon> #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 <colindixon> mohnish: is the idea that the LACP driver will actually rewrite packet_ins as they come in through the OF plugin?
19:03:11 <colindixon> if so, does it need to work with the OF plugin?
19:03:19 <mohnish> #info we are trying to preserve existing ODL apps behavior with respect to port or logical port
19:03:56 <mohnish> yes, it requires work on OF plugin
19:04:06 <colindixon> ok
19:04:10 <colindixon> abhijitkumbhare: thoughts?
19:04:48 <colindixon> #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 <colindixon> #info this would need to not apply to LACP and LLDP messages, because those need to know about physical ports
19:05:49 <abhijitkumbhare> Sorry folks - I had to take a call last 5-10 minutes -
19:06:15 <colindixon> abhijitkumbhare: while you were go we decided to rewrite the OF plugin in Lua :p
19:06:27 <dfarrell07> colindixon: roflmao
19:06:31 <abhijitkumbhare> Haha
19:06:31 <mohnish> colin: I spoke to Abhijit and he is aware of the requirement
19:06:33 <mlemay> hahaha
19:06:39 <colindixon> mohnish: cool
19:06:47 <abhijitkumbhare> I had a meeting with Mohnish & folks yesterday regarding this
19:07:05 <colindixon> would be good just to get that spoken outloud at some point
19:07:16 <abhijitkumbhare> OK
19:07:34 <mohnish> ok
19:07:43 <colindixon> 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 <colindixon> e.g., LLDP
19:08:49 <mohnish> yes... OF plugin can parse the packet in to figure out when to substitute
19:09:42 <mohnish> #info port's transition to participate in LAG requires state changes in L2switch modules
19:10:14 <colindixon> #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 <dlenrow> Is this OpenFlow specific? Why not implement as a LAG logic that can sit above any uni-link SBI?
19:12:26 <colindixon> dlenrow: my guess is that there will be a an OF-independent layer and the an OF-specific implementation
19:12:36 <dlenrow> Aren't their non-OF uni-link SBIs that will want LAG/Bonding in controller platform?
19:13:42 <colindixon> dlenrow: among other things, they will *have* use the FlowProgramming interfaces, which are only partly tied to OpenFlow
19:14:50 <colindixon> #info colindixon asks is if it’s OF-specific on behalf of dlenrow
19:15:16 <colindixon> #info the response is that it’s mostly OF-Independent except for getting packet_in/packet_out
19:15:39 <colindixon> #info response is also that it’s just using the MD-SAL FlowProgramming concepts even for the OF-specific parts
19:15:51 <dfarrell07> 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 <dlenrow> Fair enough, until we can think of another SBI that this could apply to, it's a non-issue.
19:16:24 <edwarnicke> 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 <colindixon> #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 <tykeal> dfarrell07: finding accounts based on email addresses has a 25 - 50% rate of failure for me
19:16:54 <tykeal> it's why I keep asking for everyone to put their UID in the proposals
19:17:09 <colindixon> #info LuisGomez asks if they intent to support Multi-chassis LAG, the answer is maybe in the future
19:17:14 <dfarrell07> #info tykeal asks (as always) that the committers list include UIDs
19:17:50 <tykeal> thank you!
19:17:55 <colindixon> #action mohnish will get the remaining User IDs for the project
19:17:59 <edwarnicke> 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 <edwarnicke> (not review for content, just mechanics)
19:18:16 <colindixon> edwarnicke: phrobb and I try to
19:18:23 <dfarrell07> #startvote Shall the TSC approve LACP project to Incubation? -1, 0, +1
19:18:23 <odl_meetbot> Begin voting on: Shall the TSC approve LACP project to Incubation? Valid vote options are -1, 0, +1.
19:18:23 <odl_meetbot> Vote using '#vote OPTION'. Only your last vote counts.
19:18:25 <edwarnicke> colindixon: Cool :)
19:18:28 <colindixon> #vote +1
19:18:29 <edwarnicke> #vote +1
19:18:30 <dlenrow> #vote +1
19:18:32 <jmedved> #vote +1
19:18:32 <LuisGomez> #vote +1
19:18:36 <mohnish> #vote +1
19:18:38 <ChrisPriceAB> #vote +1
19:18:40 <RajeevK> #vote +1
19:18:48 <dfarrell07> 8/13
19:18:53 <dfarrell07> #endvote
19:18:53 <odl_meetbot> Voted on "Shall the TSC approve LACP project to Incubation?" Results are
19:18:53 <odl_meetbot> +1 (8): dlenrow, jmedved, LuisGomez, edwarnicke, ChrisPriceAB, mohnish, colindixon, RajeevK
19:19:00 <colindixon> #agreed The TSC votes to move the LACP project to incubation
19:19:19 <mohnish> thanks
19:19:29 * ChrisPriceAB congrats
19:19:32 <dfarrell07> congrats LACP :)
19:19:56 <abhijitkumbhare> Congrats LACP :)
19:19:58 <dfarrell07> #topic Time Series Data Repository Creation Review
19:20:03 <colindixon> dfarrell07: thanks!
19:20:44 <colindixon> #link https://wiki.opendaylight.org/view/Project_Proposals:Time_Series_Data_Repository the project proposal
19:20:54 <colindixon> #link https://wiki.opendaylight.org/view/File:TSDR_Proposal_ODL.pptx the slides
19:21:14 <colindixon> #link https://lists.opendaylight.org/pipermail/project-proposals/2014-November/000193.html the proposal happened on 11/7/2014
19:22:14 <colindixon> #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 <colindixon> #info for Lithium the focus is on OF stats
19:22:45 <abhijitkumbhare> Interesting
19:23:36 <colindixon> if done right, this is *hugely* helpful
19:23:58 <colindixon> #info major functions are data collection, storage, queries, aggregation and purge
19:24:00 <mohnish> 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 <dbainbri> agreed, very interesting. wondering how this would relate or be a ODL implementation of something like http://opentsdb.net/
19:24:51 <colindixon> #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 <colindixon> dbainbri: good Q
19:26:03 * ChrisPriceAB apologies TSC I need to drop off the call now...
19:26:44 <ChrisPriceAB> #info ChrisPriceAB has to leave the call, abhijitkumhare will take my vote on coming actions.
19:26:46 <dbainbri> it is using HBASE as well, which is exactly what opentsdb uses
19:26:50 <mohnish> dbainbri: thought process is inline with TSDB
19:27:20 * ChrisPriceAB thanks abhijit
19:27:45 <colindixon> #info dbainbri asks if this could be done with OpenTSDB ( http://opentsdb.net/ )
19:27:46 <dbainbri> 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 <abhijitkumbhare> No problems ChrisPriceAB
19:28:22 <colindixon> #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 <mohnish> 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 <colindixon> #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 <dfarrell07> #info dfarrell07 will take over for cdub for Red Hat's vote
19:29:41 <dbainbri> mohnish: but also query the data back through MD-SAL? or only export?
19:29:45 <cdub> colindixon: dfarrell07 is my delegate
19:29:51 <colindixon> cdub: thanks!
19:30:21 <colindixon> dfarrell07 is a formidable delegate
19:30:27 <dfarrell07> colindixon: ;)
19:30:38 <mohnish> 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 <mohnish> out of TSDR ...
19:31:08 <dbainbri> any changes (Additions) to the GUI (DLUX) to be added as part of this visualizations of TSDR
19:31:21 <colindixon> #info the goal is that the TSDR could use multiple backing stores, e.g., HBase and Splunk
19:31:48 <mohnish> dbainbri: we didn't kept it in the scope ... but we can do it as futures
19:32:20 <dbainbri> generic question we are struggling with internally. when does a controller become a network management system ;)
19:33:02 <rovarga> dbainbri: yes that is a good one. esp. what precisely is the distinguishing property? ;)
19:33:11 <colindixon> #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 <colindixon> dbainbri, rovarga: about 6 months ago in ODL? maybe longer? :p
19:33:48 <dbainbri> lol
19:33:59 <mohnish> 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 <colindixon> #info mohnish says that this isn’t in the scope yet, but it could be done later?
19:34:35 <dbainbri> 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 <colindixon> 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 <colindixon> I get the feeling it’s parallel APIs using the same keys
19:35:41 <mohnish> colin: it is still in discussions with Jan Medved and others.
19:36:28 <colindixon> #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 <colindixon> #info mohnish responds that he, jmedved and other are still discussing this
19:36:49 <dbainbri> 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 <mohnish> 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 <dfarrell07> #info dfarrell07 thinks this would be useful for his work on ODL Perf and Tools sub-team of Integration team
19:37:48 <dbainbri> 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 <dbainbri> do we see TSDR specifying this?
19:38:25 <mohnish> 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 <colindixon> #info the plan is persist all the TSDR data and provide queries to get metrics from the recorded data
19:39:40 <colindixon> #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 <mohnish> I would let Yuling to answer on granularity ... she has the prototype
19:41:14 <dbainbri> 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 <colindixon> #info dbainbri asks about the granularity of the time data, e.g., OpenTSDB was only at second granularities
19:44:49 <rexpugh> Is TSDR relying on the newly proposed persistence project for the persistence API implementation?
19:44:52 <colindixon> #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 <rexpugh> I believe AAA, TSDR and AADS are consumers of the persistence project object store API's and DAO's?
19:45:37 <colindixon> #info jmedved, dbainbri, mohnish, and others talk about how performant it will be and/or needs to be
19:45:37 <mohnish> rex; we are working with Mark on the persistance API. Intending to leverage it.
19:46:13 <colindixon> #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 <rexpugh> Thanks mohnish, you and i knew that but i wanted to make sure the community knows it ;)
19:46:29 <mohnish> rex: :-)
19:48:09 <colindixon> #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 <colindixon> #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 <colindixon> #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 <dfarrell07> I have vote
19:49:56 <colindixon> #startvote Shall the TSC approve the TSDR project to incubation? +1, 0, -1
19:49:56 <odl_meetbot> Begin voting on: Shall the TSC approve the TSDR project to incubation? Valid vote options are +1, 0, -1.
19:49:56 <odl_meetbot> Vote using '#vote OPTION'. Only your last vote counts.
19:50:02 <dfarrell07> nvm, lol
19:50:02 <abhijitkumbhare> #vote +1
19:50:03 <jmedved> #vote +1
19:50:03 <RajeevK> #vote +1
19:50:06 <mohnish> #vote +1
19:50:07 <LuisGomez> #vote +1
19:50:08 <Youcef> #vote +1
19:50:09 <dfarrell07> #vote +1
19:50:10 <colindixon> #vote +1
19:50:10 <dlenrow> #vote +1
19:50:13 <kwatsen> #vote +1
19:50:15 <edwarnicke> #vote +1
19:50:26 <dfarrell07> many/13
19:50:29 <dfarrell07> #endvote
19:50:29 <odl_meetbot> Voted on "Shall the TSC approve the TSDR project to incubation?" Results are
19:50:29 <odl_meetbot> +1 (11): dlenrow, jmedved, LuisGomez, dfarrell07, edwarnicke, RajeevK, mohnish, kwatsen, colindixon, abhijitkumbhare, Youcef
19:50:38 <edwarnicke> dfarrell07: you win the call
19:50:49 <mohnish> thanks
19:50:49 <dfarrell07> #agreed TSC approves TSDR to Incubation
19:51:28 * tykeal notes missing ODL UIDs again...
19:51:39 * tykeal sighs
19:51:41 <edwarnicke> tykeal: Never stop noting that ;)
19:51:46 <dfarrell07> #info TSDR needs up update wiki with UIDs of committers
19:51:51 <dfarrell07> #action TSDR needs up update wiki with UIDs of committers
19:51:54 <dfarrell07> #undo
19:51:54 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Action object at 0x247ddd0>
19:52:08 <dfarrell07> #action mohnish needs up update wiki with UIDs of committers
19:52:15 <tykeal> dfarrell07: thanks
19:52:17 <dfarrell07> #undo
19:52:17 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Action object at 0x269ead0>
19:52:32 <dfarrell07> #action mohnish needs to update TSDR wiki with UIDs of committers
19:52:43 <dfarrell07> *finally got it right*
19:53:02 <phrobb> #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 <dlenrow> I would like to discuss some project creation process issues if we have a spare minute today
19:53:12 <colindixon> #undo
19:53:12 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x269e110>
19:53:13 <colindixon> #topic using the TSC meeting as a cross-project coordination
19:53:19 <colindixon> #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 <rgowrishankar> 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 <colindixon> #action colindixon will send mail about encouraging projects to get projects tracking what happens in the TSC
19:54:47 <colindixon> #topic supporting the AD-SAL
19:55:07 <colindixon> #info rgowrishankar points out that we’re having lots of problems with supporting the AD-SAL in Helium
19:55:17 <colindixon> #info this seems to be causing a lot of confusion among ODL users
19:55:36 <dfarrell07> +1 to user confusion (as a major contributor to ask.odl)
19:56:39 <colindixon> #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 <kwatsen> does the mix of AD-SAL and MD-SAL conflict with the singularity policy?
19:58:08 <colindixon> kwatsen: not until the project is core, and it’s the same project
19:58:21 <colindixon> which means I have no idea how singularity would apply
19:58:32 <colindixon> #info colindixon asks edwarnicke if the AD-SAL is going to be deprecated in Lithium
19:59:18 <colindixon> #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 <colindixon> #info edwarnicke says personally he would like to deprecate
19:59:34 <rovarga> unless someone steps up by ... M2 I guess, we need to move to deprecate it, I think
20:00:03 <phrobb> As per our process we would deprecate in Lithium, and remove the APIs in Beryllium, correct?
20:00:17 <dfarrell07> colindixon: I have a #action for that if you want
20:00:17 <dlenrow> Do we have a formal deprication process? I'm pretty sure it's not "ask Ed"
20:00:30 <colindixon> dlenrow: we do, it’s up to the project
20:00:37 <colindixon> deprecated in one release and can be removed in the next
20:00:39 <rovarga> dlenrow: the deprecation process is up to the project's committers
20:00:55 <dlenrow> That seems insane for dependents in community
20:01:09 <rovarga> dlenrow: in this particular case it seems the currently-active committers are not willing to maintain the feature going forward
20:01:10 <dlenrow> unilateral deprication evil wherever you put it
20:01:11 <dfarrell07> #action rgowrishankar, edwarnicke will reach out to people using AD-SAL. They should either come up with a way to maintain it or move to MD-SAL.
20:01:26 <rovarga> dlenrow: that why I said "unless someone steps up"
20:03:40 <dfarrell07> #endmeeting