14:31:59 #startmeeting Karaf Happy Hour 14:31:59 Meeting started Thu Aug 28 14:31:59 2014 UTC. The chair is edwarnicke. Information about MeetBot at http://ci.openstack.org/meetbot.html. 14:31:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:31:59 The meeting name has been set to 'karaf_happy_hour' 14:32:03 #topic Roll Call 14:32:08 #info edwarnicke 14:32:09 #info tbachman Group Based Policy 14:32:14 Please #info in :) 14:32:23 #info goldavberg lispflowmapping 14:32:43 #paulq sfc 14:32:58 Guys... I'm going to keep rollcall open till 7:35am PST... then we'll dig in :) 14:33:14 sounds good 14:33:22 edwarnicke: no problem 14:33:39 #info vjanandr snbi 14:33:41 #info George Zhao 14:33:46 #info abhijitkumbhare OpenFlow plugin 14:33:57 #info rafat odl-sdni app 14:35:45 do we have representative from snmp4sdn, snbi, oc ,pcmm and lisp 14:36:26 gzhao i infoed for lisp 14:36:47 goldavberg: thanks 14:36:58 vjanandr for snbi 14:37:09 vjanandr: great 14:37:27 #link https://git.opendaylight.org/gerrit/#/q/project:integration+status:open+message:feature,n,z <- open reviews to integration for features 14:37:59 #link https://git.opendaylight.org/gerrit/#/q/project:integration+status:merged+message:feature,n,z <- merged features to integration 14:38:19 #topic Status 14:38:24 #link https://git.opendaylight.org/gerrit/#/q/project:integration+status:open+message:feature,n,z <- open reviews to integration for features 14:38:30 #link https://git.opendaylight.org/gerrit/#/q/project:integration+status:merged+message:feature,n,z <- merged features to integration 14:38:55 gzhao: Could you #info in from those links the projects who have features merged into integration, and the ones which have reviews open for their features? 14:39:39 ed 14:39:40 #info repenno sfc 14:39:54 OK folks... please #info a brief status for where you are 14:40:05 #link https://docs.google.com/spreadsheets/d/12MWfLYNG_YO8pnUt5CrFD2xL1vHUXcmnUNrH-m6EdC0/edit#gid=0 14:40:21 #info GBP: stuck on first mvn clean install 14:40:29 #info Madhu (late than never ;) ) 14:40:43 #project in red should really get their Karaf process going 14:41:03 gzhao: we need access to read this ? 14:41:09 #info project in red should really get their Karaf process going (from gzhao) 14:41:23 #info odl-sdni App initiated Karaf locally.stuck on first mvn clean install 14:41:25 #info lispflowmapping waiting for review on https://git.opendaylight.org/gerrit/#/c/10364/ from integration team 14:41:26 (unless #project is a new meetbot command?) 14:42:10 #info projects Done and Integrated: controller, dlux, l2switch, openflow plugin, openflowjava, ovsdb, yangtools 14:42:14 #info snbi mvn clean install on feature/pom.xml fails.. 14:42:36 Madhu: mlemey owns the spreadsheet 14:42:43 vjanandr: rafat_: sounds like there are a few of us there :) 14:43:10 So... I think I am hearing a theme of being stuck on the first mvn clean install? 14:43:13 Is that right? 14:43:19 edwarnicke: sounds like it :) 14:43:31 Could folks put up some pastebins with failures to look at? 14:43:32 but not sure if there’s commonality in the reasons 14:43:43 tbachman: Who knows, we'll see what we see :) 14:44:30 Madhu: edwarnicke: I will wait till next topic after toll roll to #info in projects status 14:45:03 edwarnicke: http://pastebin.com/NXEq8ANR 14:45:11 gzhao: What would you like the next topic to be? 14:45:17 gzhao: u want an #info on each project status with karaf ? 14:45:30 edwarnicke: strange that it says jackson is missing 14:45:42 vjanandr: are you still block by bgpcep? 14:45:45 tbachman: Could you pastebin your features file? 14:45:50 edwarnicke: ^^^^ 14:45:53 oh 14:45:56 features :) 14:45:57 lol 14:46:20 Madhu: status on the spreadsheet 14:46:35 gzhao: i don't seem have access to it. 14:46:42 edwarnicke: Karaf Happy Hour? 14:46:58 edwarnicke: http://pastebin.com/TgDY0Ucy 14:47:06 #topic status 14:47:11 #chair gzhao 14:47:11 Current chairs: edwarnicke gzhao 14:47:13 Madhu: it owns by mlemey, thus I plan to info in 14:47:21 edwarnicke: http://pastebin.com/sbKrrtRs 14:47:39 okay gzhao fwiw, ovsdb features are all in integration karaf distro 14:48:07 gzhao: edwarnicke also pushed the odl-openflow-nxm-extensions feature 14:48:15 #topic Karaf Happy Hour 14:48:49 Madhu: cool 14:49:13 Madhu: show off 14:49:26 tbachman: lol.. more of motivation ? 14:49:29 lol 14:49:39 #info projects done and integrated: controller, dlux, l2swtich, openflow plugin, openflowjava, ovsdb, yangtools 14:49:50 vjanandr: It looks like there is a logging bundle missing... looking more closely 14:49:57 brb guys 14:50:08 gzhao: Could you also list the ones that are only pending review? 14:50:28 #info projects featurre in progress to tested: aaa, bgpcep, pcmm, reservation, vtn 14:51:38 #info project not started (please correct me if pending review at this moment) defense4all, gbp, lisp, sdni, sfc, oc, snmp, ttp 14:51:56 vjanandr: Did you use the directions here: https://wiki.opendaylight.org/view/Karaf:Step_by_Step_Guide 14:51:58 lisp has started 14:52:03 gzhao: how about “not finished” ;) 14:52:04 #link https://wiki.opendaylight.org/view/Karaf:Step_by_Step_Guide <- Step by Step directions 14:52:05 lol 14:52:08 ghall: Yes. a patch for Karaf support for vtn has been already merged. https://git.opendaylight.org/gerrit/#/c/9994/ 14:52:12 jk, btw 14:52:15 hi guys... I checked in aaa integration yesterday... https://git.opendaylight.org/gerrit/10417 14:52:22 I missed. 14:52:23 tbachman: that will be feature in progress category 14:52:23 CASP3R: What do you mean by lisp has started? (not quite following ;) ) 14:52:25 but... getting some failure :\ 14:52:34 https://git.opendaylight.org/gerrit/#/c/10364/ 14:52:34 debugging now... 14:52:45 gzhao: Yes. a patch for Karaf support for vtn has been already merged. https://git.opendaylight.org/gerrit/#/c/9994/ 14:52:56 CASP3R: I think they are just awaiting review, could you review them? 14:53:06 yea i was going to merge it now 14:53:17 tbachman: Looking at your features.xml now 14:53:45 edwarnicke: it’s minimal :) 14:54:05 we in lisp are also waiting for review https://git.opendaylight.org/gerrit/#/c/10364/ 14:54:18 edwarnicke: we have representatives from sdni, sfc here 14:55:01 #info sfc starting karaf today :) 14:55:02 edwarnicke: and lisp 14:55:10 hideyuki: thanks 14:55:11 tbachman: Where are you guys using jackson? 14:55:17 OpFlex 14:55:24 I mean in GBP 14:55:50 tbachman: I don't see any likely candidates in your feature file... 14:55:54 edwarnicke: we’re not delivering that separately — the code is in there, but it won’t be usable, as we’re still waiting on the agent 14:55:56 paulq: great 14:56:01 It’s only a single jar 14:56:08 which is why I was surprised :) 14:56:14 Which feature is it used in? 14:56:22 the only one in there ;) 14:56:33 edwarnicke: maybe I’m not following 14:56:35 Ah... ofoverlay 14:56:39 yeah 14:56:44 it’s all one feature atm 14:56:52 b/c that’s all we have (Proof Of Concept) 14:57:04 OpFlex code is in there, but we haven’t split these apart 14:57:12 that would be a post-helium thing 14:57:28 tbachman: Add these bundles to feature ofoverlay: 14:57:32 https://www.irccloud.com/pastebin/46LCJlrZ 14:57:46 edwarnicke: why are these needed here? 14:57:48 (just curious) 14:57:54 tbachman: Hang on, let me trim that down a bit 14:58:01 Is this going to be true of any 3rd party dependency? 14:58:11 tbachman: Minimal inclusion is the goal 14:58:16 sure 14:58:17 but 14:58:18 tbachman: Let me see if I can trim those down 14:58:26 I guess I didn’t understand this entirely 14:58:41 tbachman: You want your feature to include *just* the bundles you need to function, *nothing* else 14:58:48 Because anything else produces *bloat* 14:58:56 For example, the pom.xml for the project has lots of dependencies 14:59:08 but I didn’t think those were also required in the feature file 14:59:30 tbachman: One moment... looking at your code base :) 14:59:35 lol 14:59:52 edwarnicke: it’s more just trying to understand the concept here 14:59:52 edwarnicke: yes followed the wiki... but not sure what I am missing here.. 15:00:05 do we need to repeat every dependency in all the pom files? 15:01:03 tbachman: Not everyone, just the ones at runtime... but one moment 15:01:52 tbachman: Try just adding these three: 15:01:54 https://www.irccloud.com/pastebin/OhMI4sHx 15:02:00 And see how that goes 15:02:03 hmmm…. if that’s the case, sounds like a pom file scanner would be useful 15:02:17 #info sdni started Karaf.looks like we will be able to get through the compilation finally :) 15:02:17 vjanandr: Hmm... that's odd... because its complaining about missing a class that is explicitely in the archetypes... 15:02:22 hideyuki: 1 comment on the VTN features 15:02:26 edwarnicke: thx 15:02:29 Madhu: please. 15:02:31 * tbachman is still a bit confused 15:02:42 hideyuki: odl-vtn-manager-neutron is added to vtn-manager-all 15:03:00 hideyuki: by doing that, vtn cannot be part of compatible-with-all in integration project 15:03:05 hideyuki: hope you know that 15:03:21 hideyuki: on the integration project, you would have to create a new compatilbe-with-vtn 15:03:31 and add odl-vtn-manager-all to that. 15:03:45 tbachman: I started writing tooling like you describe... but ran out of time 15:03:46 hideyuki: this is because of the conflict it will have with other neutron southbound providers 15:04:00 edwarnicke: no worries — u r a busy fella :) 15:04:11 Madhu: Oh. That is very awsome comment! Thank you! 15:04:14 tbachman: I made things as easy as I could given the time :) 15:04:31 goldvberg: rafat_ vjanandr : May I know the status for your project? thanks 15:04:36 edwarnicke: got further — another missing dep, but now that I understand that it’s all runtime deps, I can probably move forward from here 15:04:36 hideyuki: please take a look @ the latest integration features.xml 15:04:51 i added a ovsdb specific neutron implementation compatible feature 15:04:56 which is NOT part of compatible-all 15:05:07 edwarnicke: pls chime in if you have any comments on this. 15:05:08 rafat_: is bgpcep still blocking you 15:05:16 #info rafat for odl-sdni app...we have been able to compile with Karaf successfully 15:05:20 Madhu: I'm seeing the features.xml. 15:05:24 Yes we are still stuck with bgpcep 15:05:31 edwarnicke: i think it is important for folks to know that any incompatible features must be on its own "compatible" feature group 15:05:33 gzhao: bgpcep is just awaiting review at integration I think 15:05:49 Madhu: How can we make that clearer? I *tried* to, but may have not communicated clearly enough 15:05:54 rafat_: great many thanks 15:06:05 edwarnicke: i think we are doing it now :) 15:06:19 CASP3R: Could you review the bgpcep feature because it is blocking sdni 15:06:22 integration project committers can make sure it is taken care of 15:06:31 there two BGP ones? 15:06:35 CASP3R: has been awesome with reviews... so no concerns there 15:06:36 edwarnicke: that is great, sdni has dependency on bgpcep, that is why I asked. 15:06:40 Madhu: Yes, in a point fashion... but trying to figure out how to make it clearer inline, in case folks are missing it in the instructions 15:06:41 just my 2c to watch out 15:06:54 CASP3R: Let me take a look 15:06:59 I was helping Heath out yesterday 15:08:38 CASP3R: https://git.opendaylight.org/gerrit/#/c/10345/ is the one 15:10:28 vjanandr: how is snbi goging? 15:10:58 goldvberg: did lisp start the process 15:11:21 gzhao we have a patch waiting for review in integration 15:11:26 https://git.opendaylight.org/gerrit/#/c/10364/ 15:11:59 #action gzhao need to follow up with projects: defense4all, pluginOC, SNMP4SDN, TTP 15:12:08 goldvberg: cool, thanks 15:12:08 gzhao: I was following the wiki.. not sure what I am missing.. and I must admit struggling a bit here.. :) 15:12:41 ghall: Is defense4all in Helium release? 15:13:09 #info lispflowmapping has patch pending review 15:13:43 vjanandr: no problem, just follow it and yell at here for any errors you have 15:14:38 vjanandr: Can you push what you have so I can look at it? 15:16:11 edwarnicke: sure will do.. 15:16:36 Madhu: Can you think of a way we could be clearer inline in the integration features.xml to help folks there in avoiding collisions? 15:17:01 edwarnicke: thinking.... 15:17:03 OK... so... is there anyone who has an outstanding help request that I haven't helped yet? I think everyone is working on stuff... 15:18:07 But I dont' want to leave anyone hanging... 15:18:23 Just because my memory is not at its peak 15:19:11 edwarnicke: for the Nicira extensions 15:19:30 do we reference that feature from the openflowplugin 15:19:34 or from openflowjava? 15:19:42 tbachman: I think Madhu had requested doing that feature in ovsdb 15:19:46 * tbachman goes off to look at those projects 15:19:50 tbachman: niciria extensions is done. 15:20:00 so… I get them from OVSDB? 15:20:02 tbachman: Which specific extensions do you need 15:20:03 edwarnicke: just to be clear. i didn't request :) 15:20:04 ? 15:20:13 edwarnicke: we didn't have a better option in the short-term. 15:20:22 Tests in error: 15:20:23 The bundle "org.opendaylight.groupbasedpolicy_0.1.0.SNAPSHOT [196]" could not be resolved. Reason: Missing Constraint: Import-Package: org.opendaylight.yang.gen.v1.urn.opendaylight.openflowjava.nx.match.rev140421; version="[0.0.0,1.0.0)" 15:20:25 Madhu: Did I misunderstand? I had started putting them in OFplugin and you asked me not to 15:20:44 edwarnicke: that is because you said the auto-release will break 15:20:47 I’m wondering if there’s a feature file from openflowjava to reference here 15:20:50 edwarnicke: correct me if am wrong 15:20:53 Madhu: Why would autorelease break? 15:21:11 edwarnicke: because there are a few nxm extensions that are defined in ovsdb proejct 15:21:18 and referencing it from openflowplugin 15:21:22 will cause loop. 15:21:23 Madhu: Sure... but they should each have a feature of their own 15:21:43 edwarnicke: ah. that won't be very useful for the consumers. 15:21:45 Madhu: No need for OFplugin to reference them... they would just need to reference the stuff in OFplugin, and then users would pick the extensions they need 15:21:57 Madhu: Overinclusion is actually really *nasty* for consumers 15:22:07 edwarnicke: sure... if that is requirement... lets do it 15:22:07 Its why we don't do 15:22:12 import foo.bar.* anymore 15:22:31 Madhu: Honestly... just as happy to leave the nxm extensions where they are 15:22:33 edwarnicke: i have pushed the features in ovsdb with both the extensions defined in openflowplugin and ovsdb projects 15:22:39 Madhu: But would request granular features for them 15:22:45 Madhu: So folks can avoid overinclusion 15:22:53 edwarnicke: sure. today we have the bare bones :) 15:23:01 edwarnicke: so we are okay at this point 15:23:06 Madhu: To be clear: I'm not asking to move the features to OFplugin... :) 15:23:15 * tbachman is confused 15:23:36 edwarnicke: me too ... am not requesting to keeping it in ovsdb :) 15:23:42 Madhu: I think there may have been some miscommunication between us, but I think its primary consequence is that we agreed on the 'what to do' but talked straight past each other on the 'why' 15:23:42 tbachman: lemme summarize 15:23:46 Which is pretty harmless :) 15:24:07 tbachman: we have a few extensions defined in openflowplugin 15:24:11 LOL... Madhu does is the why consquential to the what here? 15:24:13 tbachman: and a few in ovsdb project 15:24:25 Because as I said... I'm just fine with the 'what' of them being in ovsdb 15:24:47 and by defining the extensions — adding the augmentations in a yang model in your project? 15:24:56 edwarnicke: with sleepless nights... these what & why are greek and latin and i don't know those languages :) 15:25:04 LOL 15:25:06 edwarnicke: am perfectly perfectly okay with it being anywhere 15:25:08 15:25:10 edwarnicke: just that we need it 15:25:21 Madhu: Yep.. the 'what' :) 15:25:46 tbachman: yes. with the awesome open flow extensibility feature.. we can define it anywhere 15:25:52 :) 15:25:59 Madhu: I had thought you were requesting they be in ovsdb... you thought something else... not really worth disagreeing over since we both agree current placement is fine 15:26:00 tbachman: and can dynamically add it to the model tree 15:26:13 tbachman: Sorry for the confusion 15:26:16 edwarnicke: yes. we are in consensus :) 15:26:18 tbachman: Which extensions are you using? 15:26:20 edwarnicke: no worries 15:26:25 I’d have to check 15:26:29 readams created them 15:26:40 tbachman: all you need at this point is 15:26:43 Madhu: #info Madhu and edwarnicke have agreed to disagree about agreeing 15:27:06 edwarnicke: #info and I approve the above joke 15:27:31 tbachman: please take a look @ the integration project 15:27:43 we added the feature named odl-openflow-nxm-extensions 15:27:44 Madhu: will do 15:27:45 thx 15:27:52 #info 5 projects change status from not started to started this morning: GBP, Lisp, SDNi, SNBI and SFC 15:27:58 tbachman: it also has the dependency to inclue 15:28:12 that dependency should ideally go out to its own project during lithium 15:28:27 we are keeping it in ovsdb for now for release convience (as I thought) :) 15:28:36 :) 15:29:27 CASP3R: How goes the bgpcep review? 15:29:35 CASP3R: Asking so we can unstick SNDi 15:29:39 on a meeting 15:29:42 vjanandr: How are things with you? 15:29:46 CASP3R: ACK 15:31:11 Madhu: How many extensions are there now? 15:31:21 edwarnicke: trying few things.. I will push the code.. 15:32:48 vjanandr: Cool... as long as you aren't blocking on me :) 15:35:22 hmmm 15:35:32 so…. I should expect to see something in a yang file in our project 15:35:40 that augments an existing OF yang model 15:35:44 tbachman: Madhu I actually strongly suggest we *not* do blob features... they lead to massive overinclusion as time goes on... someone starts including odl-openflow-nxm-extensions because it contains 2 extensions and they need 3 of them... and then are massively bloated next release when they still just need 2 of them but now it include 100 15:35:47 in order for there to be a n extension 15:36:09 If that’s the case — I’m not seeing that in any of our yang models 15:36:12 I also recommend *against* treating -all as a top level feature instead of an index for the same reason 15:37:03 edwarnicke: am confused about your reference to -all… I don’t think I’m referencing (or including) any -all in my features file atm? 15:37:42 tbachman: You aren't... I was refering to the growing habit of listing -all as a top level feature in integration (note: this is me warning against future danger, not advocating that we don't allow -all features there) 15:37:57 tbachman: Nope, you aren't :) 15:38:01 :) 15:38:02 thx 15:38:35 tbachman: Do you have extensions in GBP project? 15:38:51 edwarnicke: I know that (somehow) we’re using them 15:39:08 I just don’t see anything in any of our yang models that augment an existing openflowplugin yang model 15:39:11 (or openflowjava) 15:39:19 tbachman: afaik 15:39:22 tbachman: either is fine... but it make a slight difference in how you do your features (if you *have* some you will want to package them as features) 15:39:30 tbachman: GBP is using the extensions defined in openflowplugin 15:39:34 ah 15:39:39 tbachman: you have 2 choices now 15:39:41 tbachman: Which extensions are you using? 15:39:48 so, that’s as edwarnicke said - there are some in the plugin, and some in OVSDB 15:39:50 tbachman: either you can use the bundles directly in your feature 15:39:51 got it 15:40:01 tbachman: Which ones though, by name? 15:40:05 tbachman: or include the feature. 15:40:15 tbachman: it depends on the features u use... 15:40:15 edwarnicke: I’d have to go code-diving 15:40:22 This was readams’ portion 15:40:25 give me a sec... 15:40:29 tbachman: in GBP.. just look @ the flowutils.java :) 15:40:31 edwarnicke this the BGP one right https://git.opendaylight.org/gerrit/#/c/10345/ 15:40:41 yeah 15:40:46 CASP3R: yes 15:40:48 tbachman: that is the place where readams added all the extension usage 15:40:54 right 15:40:56 Looking into now 15:41:06 Madhu: Could you please provide granular features for individual extensions? 15:41:12 So we don't wind up with a 15:41:19 import foo.bar.*; problem 15:41:27 edwarnicke: individual extension feature is not needed :) they can use the bundle directly :) 15:41:43 Ah...OK... they are single bundles then? 15:41:48 edwarnicke: yep. 15:41:49 * edwarnicke has fallen behind :( 15:41:59 Madhu: What other features do they need to work? 15:42:18 it would only be the ones with “extension” in the import, right? 15:42:21 Not the “match” 15:42:45 tbachman: yes. 15:42:50 http://pastebin.com/RJpuAtCm 15:42:55 has the match in there too, fwiw 15:43:09 tbachman yes. 15:43:30 tbachman: but think about this... if u want to selectively import the bundles as your dependencies... 15:43:48 then you have to follow the work I did in ovsdb 15:43:56 you can "reuse" it :) 15:44:03 :) 15:44:12 * tbachman knows how to make many new bugs with cut-and-paste 15:44:26 tbachman: don't cut-paste :) just get inspired 15:44:29 lol 15:44:38 tbachman: it has all the dependencies that you are interested it 15:44:44 I’m wondering 15:44:44 you can just selectively pick what you like 15:44:52 tbachman: but for a PoC.. i would say 15:44:55 just include the feature 15:44:59 and see if that works for u 15:45:00 the interest here is to be able to have just one project pull them in 15:45:06 Madhu: was going to the same place :) 15:45:07 lol 15:45:20 I can see in a project that would co-exist with other protocols 15:45:23 tbachman: try that out first. and if that works, then you should do what edwarnicke suggested 15:45:28 that making it a separate feature makes sense 15:45:36 but this is a one-trick-pony atm 15:45:51 tbachman: yes.. it is too last minute and hence we are taking this approach. 15:46:05 k 15:46:11 Madhu: edwarnicke thx for your help! 15:46:26 Regarding extensions overall - Long term (Lithium) - I think we should look into whether it makes sense to choose which of the following options 1) all extensions in one place - say openflow plugin or a third project; 2) scattered across projects which contribute and consume the extension 3) something else (is there any other option?) - for Helium we do whatever is the fastest :) 15:46:31 * tbachman knows edwarnicke and Madhu could be doing many other things with their time, and greatly appreciates it 15:47:07 abhijitkumbhare: i agree. but i don't encourage to see it in openflowplugin 15:47:11 * tbachman observes how “pragmatic” we become when it’s time for a release :) 15:47:22 abhijitkumbhare: just because of the fact that it is vendor agnostic 15:47:38 its better to have a project 15:47:44 called nxm-extensions 15:47:46 and place it there 15:47:57 and all of us can use it 15:48:12 Madhu: Lithium :) 15:48:15 abhijitkumbhare: do u agree ? 15:48:21 edwarnicke: ofcourse. lol 15:48:47 Sorry, Lithium ;) 15:49:02 embedded jokes! : 15:49:03 :) 15:49:04 edwarnicke: is it a joke ? 15:49:13 SEO joke 15:49:21 i thought it is seriously serious :) 15:49:22 I don’t know at the moment. My thought is not just related to nxm-extensions - but all the extensions - is it better to track them in one place or let it be scattered. But that is digressing - and a topic for Lithium. 15:49:27 Madhu: It was a jocular statement... but not quite a joke 15:49:38 The 15:49:51 Was joking about needing to mark it a joke when it was clearly heard properly :) 15:49:52 oh god. a joke on a joke 15:50:29 abhijitkumbhare: good point indeed. 15:50:41 abhijitkumbhare: so we are talking about openflow-extensions project :) 15:50:49 Madhu - just have not decided (what my thought on that is) 15:50:56 where nxm and other "open" extensions will play a role :) 15:50:58 Madhu: yes :) 15:51:14 abhijitkumbhare: so strange we call it "open" extension. 15:51:26 but it is a fact 15:51:40 when its a nicira extension ? :) 15:51:48 Madhu: As I think I have said before... nxm is weird ;) (in the sense that its a vendor extension but also open) 15:51:49 hmmm…. so, are the extensions currently exported as a feature in the openflowplugin? 15:52:10 tbachman: extensions support is 15:52:15 tbachman: not nicira extension 15:52:27 which feature? 15:52:29 abhijitkumbhare: edwarnicke yes :) 15:52:39 tbachman: features-openflowplugin 15:52:49 :) 15:52:52 tbachman: according to me that is absolutely the right thing to do 15:52:59 Madhu: thx 15:53:02 makes sense to me 15:53:04 extensions support is fully owned by openflowplugin 15:53:08