17:57:57 #startmeeting tsc 17:57:57 Meeting started Thu Dec 18 17:57:57 2014 UTC. The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html. 17:57:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:57:57 The meeting name has been set to 'tsc' 17:58:03 #topic roll call and agenda bashing 17:58:27 I know we’re 3 minutes early 17:58:45 #link https://wiki.opendaylight.org/view/TSC:Main#Agenda the agenda in it’s usual place 17:59:35 #info edwarnicke 18:00:08 #info Chris Price 18:00:32 Sounds like an ER in here... 18:00:46 haha 18:01:13 #info colindixon 18:01:18 #info dlenrow 18:01:33 #info kwatsen 18:01:37 #link https://meetings.opendaylight.org/opendaylight-meeting/2014/tsc/opendaylight-meeting-tsc.2014-12-11-17.59.html last weeks meeint minutes for action items 18:01:59 #action colindixon to start the conversation and collect ideas on how to resolve cross-project version bumping in timely fashion 18:02:18 #info the CAPWAP project proposal was approved over e-mail vote 18:03:05 #info Chris Wright 18:03:58 #info phrobb and colindixon will help to clean up the non-projects from the wiki 18:04:13 #undo 18:04:13 Removing item from minutes: 18:04:20 #action phrobb and colindixon will help to clean up the non-projects from the wiki 18:04:27 #action colindixon will try to explore the use categories which allow for easier curation of this 18:05:23 "gzhao will fill in the Duan Jingzhu’s username" 18:05:47 #info mohnish anumala 18:05:55 #info regXboi 18:05:56 #action colindixon to follow up with tykeal on getting usernames for new projects 18:06:12 #action colindixon will send mail about encouraging projects to get projects tracking what happens in the TSC 18:07:36 #info jmedved 18:08:11 #action colindixon will track how VTN and controller are interacting on possible AD-SAL deprecation 18:08:44 #info LuisGomez 18:08:55 * ChrisPriceAB you have me for the next 14% battery power :s 18:09:08 I'm here 18:09:10 #chair dfarrell07 regXboi 18:09:10 Current chairs: colindixon dfarrell07 regXboi 18:09:35 use the handle! :D 18:09:44 * regXboi not on phone yet 18:09:59 #topic updates 18:10:07 kk 18:10:37 #info Event updates from Phil: IRC event email sent, presentations for summit now being accepted 18:10:41 I can grab links 18:10:53 #link https://lists.opendaylight.org/pipermail/tsc/2014-December/002359.html IRC meetings between M1 and M2 18:11:07 #link http://www.opendaylight.org/events/2015-07-27/opendaylight-summit CFP for ODL Summit 18:11:14 #link https://lists.opendaylight.org/pipermail/tsc/2014-December/002357.html conversation about f2f meetings in April 18:12:01 #info LuisGomez will remove old Hydrogen distros from stable/helium and master 18:12:11 #link https://lists.opendaylight.org/pipermail/tsc/2014-December/002351.html Luis will remove Hydrogen distributions unless there are any objections 18:12:20 #undo 18:12:20 Removing item from minutes: 18:12:24 #link https://lists.opendaylight.org/pipermail/tsc/2014-December/002351.html Luis will remove Hydrogen distributions unless there are any objections *today* 18:13:30 #info Li and stable/helium updates: zxiiro has made progress, more TODOs; SR1.1 security release coming out 18:13:44 #info tykeal is making progress on ODL Forge 18:14:03 #info tykeal is having to build better Jenkins Puppet modules, which is a bit of the holdup 18:14:12 #info tykeal predicts ODL Forge will be ready in Jan 18:14:36 dfarrell07: better gerrit puppet module 18:14:47 tykeal: oops 18:14:49 #topic Helium SR1.1 Release 18:14:53 it's ok, I didn't specify ;) 18:15:19 #info Security vul was pointed out on mailing lists a few days ago 18:15:42 #info Three patches have been cherry picked into SR1 to fix them, that will be SR1.1 18:16:22 #info Low risk of bugs being introduced by SR1.1 changes, LuisGomez has validated that it's fairly robust 18:16:25 colindixon: kk 18:16:47 #link https://lists.opendaylight.org/pipermail/release/2014-December/001061.html Luis says it is as good or better than SR1 18:17:08 #link http://nexus.opendaylight.org/content/repositories//staging/org/opendaylight/integration/distribution-karaf/0.2.1-Helium-SR1.1/ The Helium-SR1.1 artifacts are ready to go here 18:17:33 I know 18:18:01 #startvote Shall the TSC bless the release of SR1.1? -1, 0, 1 18:18:01 Begin voting on: Shall the TSC bless the release of SR1.1? Valid vote options are -1, 0, 1. 18:18:01 Vote using '#vote OPTION'. Only your last vote counts. 18:18:08 #vote +1 18:18:08 jmedved: +1 is not a valid option. Valid options are -1, 0, 1. 18:18:10 #vote +1 18:18:10 colindixon: +1 is not a valid option. Valid options are -1, 0, 1. 18:18:10 #vote 1 18:18:13 #vote +1 18:18:13 LuisGomez: +1 is not a valid option. Valid options are -1, 0, 1. 18:18:14 #vote 1 18:18:17 #vote 1 18:18:17 #vote 1 18:18:19 oops! 18:18:23 #vote 1 18:18:23 sorry all :( 18:18:23 #vote 1 18:18:24 #vote 1 18:18:24 #vote 1 18:18:33 #vote 1 18:18:55 #vote +1 18:18:55 dlenrow: +1 is not a valid option. Valid options are -1, 0, 1. 18:19:02 cdub: want to get that vote in? 18:19:05 #vote 1 18:19:06 o, gtg 18:19:10 #endvote 18:19:10 Voted on "Shall the TSC bless the release of SR1.1?" Results are 18:19:10 1 (10): dlenrow, jmedved, regXboi, LuisGomez, ChrisPriceAB, edwarnicke, cdub, mohnish, kwatsen, colindixon 18:19:11 #endvote 18:19:12 #vote 1 18:19:12 * ChrisPriceAB well done all involved! 18:19:28 RajeevK: sorry bout that 18:19:36 dfarrell07: ? 18:19:42 #agreed The TSC blessed the release of SR1.1 18:20:00 cdub: I had some IRC lag, nvm 18:20:09 ah, ok 18:21:00 #info TSC discusses SR2 release date 18:21:10 #action colindixon to post SR1.1 to the security advisories mailing list and possibly to opendaylight-annoucne mailing list 18:21:23 #info SR2 release date will be taken to a thread 18:21:29 * ChrisPriceAB Early February please 18:21:37 #action gzhao (or colindixon) to start a thread on possibly moving SR2 further out than 1/12 18:22:10 #topic Security Response Process 18:22:34 #info New process has been reviewed and approved over the past few days 18:23:06 #info There is a security list, it will be better publicized than it was before 18:23:32 #info Discussion about members of security response team 18:24:23 #info rovarga cdub edwarnicke are up to be voted into security response team 18:24:50 #info regXboi has asked on-thread to be removed from team 18:26:10 All-star team! 18:27:29 colindixon: Why not do the following : 18:27:35 colindixon: 1. Email to security list comes in 18:27:42 2. Ticket in bugzilla gets raised 18:27:44 #link https://lists.opendaylight.org/pipermail/tsc/2014-December/002281.html Thread where TSC voted on security team actions 18:27:52 3. It has to be assigned to someone, if not, it gets auto-escalated 18:28:13 Seems pretty simple to me 18:28:17 cdub: colindixon rovarga Shall we hash out mechanical details on discuss under topic [Security Mechanics] ? 18:29:12 missing a name 18:29:15 edwarnicke: yes, and given global nature, topic in email is good 18:29:16 David and ... 18:29:18 * Chris Wright 18:29:19 * Ed Warnicke 18:29:19 * Robert Varga 18:29:22 David Jorm 18:29:26 Kurt Seifried 18:29:33 cdub: Would you be willing to kick off ? 18:29:44 #startvote Shall the TSC approve cdub rovarga edwarnicke David Jorm Kurt Seifried to be members of the security response team? -1, 0, +1 18:29:44 Begin voting on: Shall the TSC approve cdub rovarga edwarnicke David Jorm Kurt Seifried to be members of the security response team? Valid vote options are -1, 0, +1. 18:29:44 Vote using '#vote OPTION'. Only your last vote counts. 18:29:48 #vote +1 18:29:50 #vote +1 18:29:51 #vote +1 18:29:51 edwarnicke: yes 18:29:52 lol ;) 18:29:52 #vote +1 18:29:53 #vote +1 18:29:54 #vote +1 18:29:54 #vote +1 18:29:56 #vote +1 18:29:56 #vote +1 18:29:56 #vote +1 18:29:57 #vote +1 18:30:10 #endvote 18:30:10 Voted on "Shall the TSC approve cdub rovarga edwarnicke David Jorm Kurt Seifried to be members of the security response team?" Results are 18:30:10 +1 (11): dlenrow, jmedved, regXboi, LuisGomez, ChrisPriceAB, edwarnicke, cdub, mohnish, kwatsen, colindixon, RajeevK 18:30:21 #action cdub to kick off security mechanics email discussion 18:30:31 * regXboi is happy with that 18:30:39 #agreed The TSC approved cdub rovarga edwarnicke David Jorm Kurt Seifried to be members of the security response team 18:32:38 yes, done 18:32:43 #action Someone will test the security mailing list (cdub?) 18:33:04 #topic CAPWAP creation review 18:33:14 #info the CAPWAP project was approved on the mailing list 18:33:19 #topic Project Creation Review for Persistence Project 18:33:59 #link https://wiki.opendaylight.org/view/Project_Proposals:Persistence project proposal 18:34:22 #link https://lists.opendaylight.org/pipermail/project-proposals/2014-December/000217.html proposed on 12/3/2014 18:34:58 @colindixon feel free to #chair me 18:35:07 #chair phrobb 18:35:07 Current chairs: colindixon dfarrell07 phrobb regXboi 18:35:10 thanks 18:35:45 help taking notes for project proposals is always welcome 18:35:56 :-D 18:36:01 especially from people who are more familiar 18:36:09 #link https://wiki.opendaylight.org/view/File:Peristence-Project-Proposal-TSC-Presentation.pptx slides on the wiki 18:36:52 #info the basic idea is to have a query-able, persistent data store API (and different back databases) 18:38:27 #info AAA and TSDR are projects that will look into usin this project 18:38:35 #link https://wiki.opendaylight.org/view/Project_Proposals:Persistence Persistence Proposal wiki 18:39:24 #undo 18:39:24 Removing item from minutes: 18:39:32 dfarrell07: that’s posted above 18:39:44 colindixon: ah, ic, sorry 18:39:47 A few questions: 18:40:03 1.) I don’t think AADS is a project (or proposal) yet that I know of. 18:40:47 2.) Is the intent to have a simple-to-set-up and works-out-of-the-box implementation to make it so that you can run ODL with persistance without having to also deploy a DBMS? (edwarnicke’s favorite question) 18:42:27 has anybody gotten cdub's mail? 18:43:15 3.) #2 is especially complex if you’re saying that the things would help set stuff up is not in scope 18:44:10 #Info jmedved asks how does this persistance relate to the persistance provided by the clustered data store 18:44:47 #info answer is that this will support non-modeled data and will allow for data sets that don’t fit entirely in-memory 18:45:13 Yes AADS is not a project proposal yet. We are rethinking the idea and may not go forward in the current form 18:46:16 #info edwarnicke asks if there has been thought about how to handle DB schemas? 18:46:48 #Info the answer is that implementations will almost certainly have to have knowleded of the particular schema of the particular database 18:47:00 Sunil_: thanks 18:49:42 #info discussing schema definition which is currently considered "left to implementations" 18:49:51 oops, sorry, i was scrolled up 18:50:01 #link https://wiki.opendaylight.org/view/Project_Proposals:Persistence#Schema_Definition_is_Left_to_the_Implementations_and_not_Considered_as_Part_of_the_API discussing this part of proposal 18:50:32 so does that mean that the applications are tied to the backing datastore implementation? 18:50:54 #info edwarnicke points out that the deployment model for ODL could be greatly complicated by this project 18:50:55 e.g. what are we envisioning the mobility will be here? 18:51:40 #info regXboi notes that you really don’t want to get into storing all the data for stats in the clustered store, so TSDR desperately wantst this project 18:51:41 * ChrisPriceAB has to step away for a bit... 18:51:59 #info ODL also runs on tons of systems (anything that supports Java), which could be broken by deps of this project (like MySQL) 18:52:05 #info edwarnicke asks what the story for out-of-the-box functionality 18:52:05 sqlite3? 18:52:19 it's cheap and cheesy - but it runs on linux, windows and mac 18:52:53 right, but as far as I know the java impl relies on JNI 18:52:57 #info if we instead require people to set up an external DBMS to get things work at all, this is really much harder 18:54:33 #info Liem responds saying, like AAA, this should likely work out-of-the-box with one implementation, but then can swap out the DBMS as a configuration option 18:55:29 I didn't think that I need JNI, if I have JDBC 18:55:47 Maybe things that need a high-performance persistence/IO solution (e.g. time series) don't run out of the box or on laptops. Maybe features that need advanced persistence don't work without the setup cost of deploying advanced database/back-end 18:56:06 dlenrow: That's fine, as long as nothing important depends on them... 18:56:07 #info lots more discussion, but the net-net seems to be that we need to figure out how to run portably across different DBs including ones that can be run out-of-the-box as well as different external ones 18:56:43 colin: This seems like a project work product not a creation review 18:56:57 dlenrow: cdub has it 18:57:02 +1 18:57:25 scope: solve this problem. Approved! 18:58:01 include out of box works as a goal and get on with it? 18:58:28 #info cdub points out that details should be fleshed out as Persistence project develops, not relevant to valid/not-valid Incubation project 18:59:23 colindixon: +1 18:59:29 #startvote Shall the TSC approve the Persistence Project to Incubation? -1, 0, +1 18:59:29 Begin voting on: Shall the TSC approve the Persistence Project to Incubation? Valid vote options are -1, 0, +1. 18:59:29 Vote using '#vote OPTION'. Only your last vote counts. 18:59:36 #vote +1 18:59:39 #vote +1 18:59:43 #vote +1 18:59:45 #vote +1 18:59:47 #vote +1 18:59:49 #vote +1 18:59:52 #vote +1 18:59:54 #vote +1 18:59:58 #vote +1 19:00:02 9/13 19:00:06 #endvote 19:00:06 Voted on "Shall the TSC approve the Persistence Project to Incubation?" Results are 19:00:06 +1 (9): dlenrow, regXboi, LuisGomez, ChrisPriceAB, RajeevK, cdub, mohnish, edwarnicke, colindixon 19:00:18 #agreed TSC approved Persistence Project to Incubation 19:00:28 past tense? 19:00:35 present tense? 19:00:35 #undo 19:00:35 Removing item from minutes: 19:00:46 #agreed TSC approves Persistence Project to Incubation 19:00:49 :) 19:00:52 regXboi: thanks :) 19:01:02 no worries - you just beat me to it :) 19:01:21 Congrats Persistence project :D 19:01:22 * regXboi is of the opinion that sqlite3 should be looked at for the "out of the box" code 19:01:30 #topic Project Creation Review for SNMP Plugin Project 19:01:39 * regXboi admits that is just his opinion 19:01:50 Nice job persistence team 19:01:53 i liked "who should the ball get?" 19:01:59 #link https://lists.opendaylight.org/pipermail/project-proposals/2014-December/000222.html Proposed 12/5/2014 19:02:04 #info security list test passed!!! 19:02:06 cdub: yeah 19:02:08 :-) 19:02:23 * ChrisPriceAB poor Steve, gotten by the ball... 19:02:26 #link https://wiki.opendaylight.org/view/Project_Proposals:SNMP_Plugin SNMP Plugin Project Proposal wiki 19:03:02 colindixon: I don't know where you find the slide links 19:03:32 dfarrell07: I don’t see the slides 19:03:39 dlenrow: do you know where/if sldes are? 19:05:14 #info the project started as just wanted to read out a single value to identify a device via SNMP, but do so in a more reusable way 19:05:16 liemmn: Do you know where slides are? Can you upload/#link? 19:05:22 #info Basic idea is to add a SB SNMP plugin 19:05:43 #info Will use MD-SAL 19:05:46 #Info it turned out that there was an effort in Cisco to support SNMP by converting MIBs to YANG models 19:05:52 #info this project will start with and extend that code base 19:06:33 #info basic arch is to take SNMP MIBs, turn them into YANG models, and then turn that into Java code and use it it in the MD-SAL as usual 19:08:22 Yangtools forgotten again ;) 19:08:25 yangtools is a dependency :) 19:08:34 ChrisPriceAB: thanks :) 19:08:39 spin the vote! 19:08:48 * ChrisPriceAB np ;) 19:09:01 #info Initial committers list is better than average, tykeal may still need ODL usernames 19:09:32 haha... dfarrell07 I see IRC handles not ODL identities ;) 19:09:50 tykeal: yeah, saw that, lol 19:09:53 at least it gives me another handle on people... 19:09:56 architecturally, snmp4sdn should actually end up using this project to access the switches 19:09:57 lol 19:09:57 no pun intended ;) 19:09:58 #info cdub asks if there’s an effort to integration the SNMP efforts between this and SNMP4SDN 19:10:01 ODL usernames on project proposal page 19:10:17 uchau: I don't see them: https://wiki.opendaylight.org/view/Project_Proposals:SNMP_Plugin#Initial_Committers 19:10:23 #info the answer is none so far, except that the two uses are separate for now 19:10:53 uchau: unless IRC handles are == ODL usernames for these folks 19:11:18 that's not always true, in fact it seems to be fairly rarely true in my experience 19:11:41 #info in the long run it would be good if the SNMP4SDN project could be migrated (in a friendly way) to using the SNMP plugin rather than just the snmp4j library 19:11:41 i believe they are mislabeled as IRC. 19:11:44 in the snmp context, this project would be the equivalent of openflowjava, whereas snmp4sdn is the equivalent of openflowplugin 19:11:53 * tykeal hopes so 19:12:00 rovarga: thanks, better 19:12:06 rovarga: I guess that’ snot how I’d see 19:12:07 it 19:12:22 nateharmon: Cool, thanks for info. :) 19:12:28 rovarga: I’d see SNMP as ~= (OpenFlow Java + OpenFlowPlugin) 19:12:28 heh, actually, i thin kthat's how they originally proposed it 19:12:56 OpenFlowJava has no state machines or operations, just modles 19:12:57 and feedback was, md-sal + yang mibs, makes it look more like openflowplugin (to me, maybe i'm offbase) 19:12:57 whereas it sounds like this will 19:13:04 colindixon: well. snmp4sdn achieves OF-equivalence using SNMP as the control protocol 19:13:23 #info LuisGomez asks if there will be any interactions with NSFs 19:13:29 at least that's my understanding 19:13:51 #info the answer seems to be not directly, but only by creating data in the MD-SAL, not interacting with the NSFs directly 19:13:58 I agree with colindixon - this looks ~= (OpenFlow Java + OpenFlowPlugin) 19:15:11 heh, standard mibs 19:15:18 #info LuisGomez asks where the MIBs will come from 19:15:21 nearly an oxymoron for real life 19:15:50 #info answer is this will depend on who’s using it, projects will bring in their own MIBs 19:16:16 abhijitkumbhare: it is slightly different. (OpenFlow Java + OpenFlowPlugin) do not expose nodes directly to end users in their own md-sal context. they provide an rpc api. this is really more similar to the netconf connector 19:16:42 Ack jmedved 19:16:56 is there automagic mib -> yang model generation? 19:17:23 #info the answer is that you can bring along your MIBs after the fact in your own project, largely by bringing along YANG files generated from the MIBs 19:17:24 * ChrisPriceAB loves automagic 19:17:29 #info from MD-SAL perspective, we want to follow pretty much the same way we work with yang 19:17:38 cdub: I think there’s something called LiveSMI or something 19:17:55 #info which means that some use-cases need compile-time, but the runtime component is completely dynamic 19:17:59 colindixon: thanks 19:18:08 #startvote Shall the TSC approve the SNMP Plugin Project to Incubation? -1, 0, +1 19:18:08 Begin voting on: Shall the TSC approve the SNMP Plugin Project to Incubation? Valid vote options are -1, 0, +1. 19:18:08 Vote using '#vote OPTION'. Only your last vote counts. 19:18:13 #vote +1 19:18:16 #vote +1 19:18:16 #vote +1 19:18:19 #vote +1 19:18:21 #vote +1 19:18:22 #vote +1 19:18:23 #vote +1 19:18:24 #vote +1 19:18:32 that's 8/13 19:18:35 #vote +1 19:18:40 9/13 now :) 19:18:40 cdub: LibSMI, not LiveSMI 19:18:42 #vote +1 19:18:43 #endvote 19:18:43 Voted on "Shall the TSC approve the SNMP Plugin Project to Incubation?" Results are 19:18:43 +1 (10): dlenrow, regXboi, LuisGomez, ChrisPriceAB, edwarnicke, RajeevK, cdub, mohnish, kwatsen, colindixon 19:18:51 #agreed TSC approves SNMP Plugin Project to Incubation 19:18:56 pretty interesting 19:19:02 cdub: it's specified by RFC6643 19:19:08 rexXboi: You're almost as good at vote counting as meetbot :) 19:19:21 #topic Project Creation Review for Topology Processing Framework Project 19:19:22 who is rexXboi? 19:19:30 #link https://wiki.opendaylight.org/view/Project_Proposals:Topology_Processing_Framework Topology Processing Framework Project Proposal wiki 19:19:34 #link https://lists.opendaylight.org/pipermail/project-proposals/2014-December/000219.html Proposed 12/4/2014 19:19:35 :) 19:19:38 rexboi: Your xrated cousin? 19:19:49 rovarga: cool, thank you 19:19:58 no - but I have a cousin jack who might answer that dlenrow :) 19:20:00 some audio problem 19:20:08 i can hear you 19:20:21 reconnecting 19:20:26 #info having trouble with audio of Topo folks 19:20:49 #topic Project Creation Review for Maple Project 19:21:16 wow - was the depth of that shared screen pi/2? 19:21:24 #link https://wiki.opendaylight.org/view/Project_Proposals:Maple Maple Project Proposal wiki 19:21:40 #link https://lists.opendaylight.org/pipermail/project-proposals/2014-December/000218.html Proposed 12/4/2014 19:21:56 #link https://wiki.opendaylight.org/view/File:MapleInODL.pptx slides in pptx format 19:22:02 #link https://wiki.opendaylight.org/view/File:MapleInODL.pdf slides in PDF 19:22:06 dfarrell07: thanks! 19:23:03 #Info Maple as a platform for doing flow programming SDN, e.g., OpenFlow, with it’s own stand-alone controller for now 19:23:22 #info this is a proposal to port that to OpenDaylight 19:24:30 #info Maple allows people to define a single, high-level packet processing function that will be logically applied to every packet that enters the network 19:24:34 um 19:24:47 http://www.ece.cmu.edu/~ece739/papers/maple.pdf 19:24:52 colindixon: the obvious question is greenfield 19:24:56 and brownfield 19:25:30 #info this is not actually done in this way, but instead compiled into rules that are installed in the network combined with packet_in handlers 19:25:34 regXboi: ack 19:25:37 or when we have a mathematcia project 19:25:43 * regXboi not sure how useful this is if there are projects that don't use it 19:26:03 * regXboi admits it interesting, but ... 19:26:29 mohnish: It'd be cool if you'd `#link description` that :) (or I can do it, of course) 19:26:47 #link http://www.ece.cmu.edu/~ece739/papers/maple.pdf 19:26:48 regXboi: so, even if it doesn’t work if other projects don’t use it, the project’s utility for people that do want to use it seems worth bringing in 19:26:50 regXboi: thanks 19:26:53 #undo 19:26:53 Removing item from minutes: 19:27:07 #link http://www.ece.cmu.edu/~ece739/papers/maple.pdf the academic paper explaining the base of the project 19:27:15 * colindixon likes context for links :-) 19:27:30 Anyone else getting an error 31001 when trying to join the meeting with Android's WebEx client? 19:27:36 regXboi: thanks 19:27:41 colindixon: if the point is to have the context of flow table rules, then having a way to import rules back into some guessed context might be .... useful 19:27:44 dneary: that's how i'm on 19:27:48 (no error) 19:28:01 dneary: I hit that error last week, haven't tried this week 19:28:08 cdub, Meeting # 194 548 370? 19:28:15 regXboi: +1 great suggestion to make and question to answer 19:28:15 dneary: I'm in on my tablet 19:28:19 Could be "meeting full", I guess 19:28:25 dneary: yes 19:28:54 I did have a problem a couple weeks back and it wouldn't go away until I rebooted my tablet 19:29:29 #info the packet processing function is analyzed whenever it’s run on a packet_in which gives a trace tree of know control flows through the function, the trace tree can then be turned to flows in flow tables in a very nice way 19:29:29 * dfarrell07 grumbles at WebEx (not that there are great alternatives, they all suck) 19:29:40 dfarrell07: so very true 19:29:45 Is this purely a reactive programming model? No flow rules until flow miss and packet in? 19:29:59 dneary: we try to make it so we only use webex for audio and post slides/links in IRC 19:30:08 dlenrow: that's a reasonable question 19:30:14 colindixon, OK, thanks 19:30:31 dlenrow: Good question to bubble up to Andi :) 19:30:35 Looking for slides... 19:30:45 dneary: they are #link'd in above 19:31:00 dlenrow: I think no because you can do some static analysis of the function, but I don’t know 19:31:01 dneary: https://wiki.opendaylight.org/images/d/d8/MapleInODL.pdf (if you don't have scroll back) 19:31:07 dneary: https://wiki.opendaylight.org/view/File:MapleInODL.pdf 19:31:14 IRC ftw 19:31:18 currently on slide 9 19:31:51 #info you can take multiple packet processing functions and compose them into a larger function, but you still need some top-level function 19:33:56 #info scope is to provide the Java-based programming abstraction ODL that provides the compiler, runtime, etc. to do this for OpenFlow with packet functions and maybe look at doing SFC and GBP like things on top of it as a proof-of-concept 19:34:08 #info jmedved asks what they do with runtime tracing 19:35:04 #info AndreasVoellmy says they basically capture accesses to the data that’s given to the packet processing function to know what information was used by the function to build the trace tree 19:35:11 #Info jmedved asks how to debug programs like this 19:35:51 Phrase of the meeting "Motherhood and Apple Pie" 19:36:16 #info AndreasVoellmy responds that you could debug this in the non-flow-table space, but you’d need to trust the compiler that takes the packet processing functions to flows in flow tables 19:36:50 #info regXboi asks how do you deal with the fact that, in ODL, many projects write flows directly and how does that perturb the approach 19:36:53 regXboi: would that mean that the network is controller in multiple ways at the same time? 19:37:13 rovarga: today there are multiple things writing flow tables 19:37:16 #info AndreasVoellmy says that you can reverse-engineer the function from the flow table, but you lose the context and other advantages 19:37:24 and I'm thinking of how this will work in that case 19:37:41 #Info AndreasVoellmy says that the current model is that they are the only people writing flows, but he thinks it can be extended to handle this case 19:37:52 oflibMichal1: do you know if you have audio fixed? 19:37:56 regXboi: sounds like trouble 19:38:13 regXboi: so if there are multiple writers, who is making sure the combination actually does what the two writers actually want to do? 19:38:16 colindixon: i tried and it worked 19:38:24