14:31:59 <edwarnicke> #startmeeting Karaf Happy Hour
14:31:59 <odl_meetbot> 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 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:31:59 <odl_meetbot> The meeting name has been set to 'karaf_happy_hour'
14:32:03 <edwarnicke> #topic Roll Call
14:32:08 <edwarnicke> #info edwarnicke
14:32:09 <tbachman> #info tbachman Group Based Policy
14:32:14 <edwarnicke> Please #info in :)
14:32:23 <goldavberg> #info goldavberg lispflowmapping
14:32:43 <paulq> #paulq sfc
14:32:58 <edwarnicke> Guys... I'm going to keep rollcall open till 7:35am PST... then we'll dig in :)
14:33:14 <paulq> sounds good
14:33:22 <gzhao> edwarnicke: no problem
14:33:39 <vjanandr> #info vjanandr snbi
14:33:41 <gzhao> #info George Zhao
14:33:46 <abhijitkumbhare> #info abhijitkumbhare OpenFlow plugin
14:33:57 <rafat_> #info rafat odl-sdni app
14:35:45 <gzhao> do we have representative from  snmp4sdn, snbi, oc ,pcmm and lisp
14:36:26 <goldavberg> gzhao i infoed for lisp
14:36:47 <gzhao> goldavberg: thanks
14:36:58 <vjanandr> vjanandr for snbi
14:37:09 <gzhao> vjanandr: great
14:37:27 <edwarnicke> #link https://git.opendaylight.org/gerrit/#/q/project:integration+status:open+message:feature,n,z <- open reviews to integration for features
14:37:59 <edwarnicke> #link https://git.opendaylight.org/gerrit/#/q/project:integration+status:merged+message:feature,n,z <- merged features to integration
14:38:19 <edwarnicke> #topic Status
14:38:24 <edwarnicke> #link https://git.opendaylight.org/gerrit/#/q/project:integration+status:open+message:feature,n,z <- open reviews to integration for features
14:38:30 <edwarnicke> #link https://git.opendaylight.org/gerrit/#/q/project:integration+status:merged+message:feature,n,z <- merged features to integration
14:38:55 <edwarnicke> 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 <gzhao> ed
14:39:40 <repenno> #info repenno sfc
14:39:54 <edwarnicke> OK folks... please #info a brief status for where you are
14:40:05 <gzhao> #link https://docs.google.com/spreadsheets/d/12MWfLYNG_YO8pnUt5CrFD2xL1vHUXcmnUNrH-m6EdC0/edit#gid=0
14:40:21 <tbachman> #info GBP: stuck on first mvn clean install
14:40:29 <Madhu> #info Madhu (late than never ;) )
14:40:43 <gzhao> #project in red should really get their Karaf process going
14:41:03 <Madhu> gzhao: we need access to read this ?
14:41:09 <tbachman> #info project in red should really get their Karaf process going (from gzhao)
14:41:23 <rafat_> #info odl-sdni App initiated Karaf locally.stuck on first mvn clean install
14:41:25 <goldavberg> #info lispflowmapping waiting for review on https://git.opendaylight.org/gerrit/#/c/10364/ from integration team
14:41:26 <tbachman> (unless #project is a new meetbot command?)
14:42:10 <gzhao> #info projects Done and Integrated: controller, dlux, l2switch, openflow plugin, openflowjava, ovsdb, yangtools
14:42:14 <vjanandr> #info snbi mvn clean install on feature/pom.xml fails..
14:42:36 <gzhao> Madhu: mlemey owns the spreadsheet
14:42:43 <tbachman> vjanandr: rafat_: sounds like there are a few of us there :)
14:43:10 <edwarnicke> So... I think I am hearing a theme of being stuck on the first mvn clean install?
14:43:13 <edwarnicke> Is that right?
14:43:19 <tbachman> edwarnicke: sounds like it :)
14:43:31 <edwarnicke> Could folks put up some pastebins with failures to look at?
14:43:32 <tbachman> but not sure if there’s commonality in the reasons
14:43:43 <edwarnicke> tbachman: Who knows, we'll see what we see :)
14:44:30 <gzhao> Madhu: edwarnicke: I will wait till next topic after toll roll to #info in projects status
14:45:03 <tbachman> edwarnicke:  http://pastebin.com/NXEq8ANR
14:45:11 <edwarnicke> gzhao: What would you like the next topic to be?
14:45:17 <Madhu> gzhao: u want an #info on each project status with karaf ?
14:45:30 <tbachman> edwarnicke: strange that it says jackson is missing
14:45:42 <gzhao> vjanandr: are you still block by bgpcep?
14:45:45 <edwarnicke> tbachman: Could you pastebin your features file?
14:45:50 <tbachman> edwarnicke: ^^^^
14:45:53 <tbachman> oh
14:45:56 <tbachman> features :)
14:45:57 <tbachman> lol
14:46:20 <gzhao> Madhu: status on the spreadsheet
14:46:35 <Madhu> gzhao: i don't seem have access to it.
14:46:42 <gzhao> edwarnicke: Karaf Happy Hour?
14:46:58 <tbachman> edwarnicke: http://pastebin.com/TgDY0Ucy
14:47:06 <edwarnicke> #topic status
14:47:11 <edwarnicke> #chair gzhao
14:47:11 <odl_meetbot> Current chairs: edwarnicke gzhao
14:47:13 <gzhao> Madhu: it owns by mlemey, thus I plan to info in
14:47:21 <vjanandr> edwarnicke: http://pastebin.com/sbKrrtRs
14:47:39 <Madhu> okay gzhao fwiw, ovsdb features are all in integration karaf distro
14:48:07 <Madhu> gzhao: edwarnicke also pushed the odl-openflow-nxm-extensions feature
14:48:15 <gzhao> #topic Karaf Happy Hour
14:48:49 <gzhao> Madhu: cool
14:49:13 <tbachman> Madhu: show off
14:49:26 <Madhu> tbachman: lol.. more of motivation ?
14:49:29 <tbachman> lol
14:49:39 <gzhao> #info projects done and integrated: controller, dlux, l2swtich, openflow plugin, openflowjava, ovsdb, yangtools
14:49:50 <edwarnicke> vjanandr: It looks like there is a logging bundle missing... looking more closely
14:49:57 <Madhu> brb guys
14:50:08 <edwarnicke> gzhao: Could you also list the ones that are only pending review?
14:50:28 <gzhao> #info projects featurre in progress to tested: aaa, bgpcep, pcmm, reservation, vtn
14:51:38 <gzhao> #info project not started (please correct me if pending review at this moment) defense4all, gbp, lisp, sdni, sfc, oc, snmp, ttp
14:51:56 <edwarnicke> vjanandr: Did you use the directions here: https://wiki.opendaylight.org/view/Karaf:Step_by_Step_Guide
14:51:58 <CASP3R> lisp has started
14:52:03 <tbachman> gzhao: how about “not finished” ;)
14:52:04 <edwarnicke> #link https://wiki.opendaylight.org/view/Karaf:Step_by_Step_Guide <- Step by Step directions
14:52:05 <tbachman> lol
14:52:08 <hideyuki> ghall: Yes. a patch for Karaf support for vtn has been already merged. https://git.opendaylight.org/gerrit/#/c/9994/
14:52:12 <tbachman> jk, btw
14:52:15 <liemmn> hi guys... I checked in aaa integration yesterday...  https://git.opendaylight.org/gerrit/10417
14:52:22 <hideyuki> I missed.
14:52:23 <gzhao> tbachman: that will be feature in progress category
14:52:23 <edwarnicke> CASP3R: What do you mean by lisp has started? (not quite following ;) )
14:52:25 <liemmn> but... getting some failure :\
14:52:34 <CASP3R> https://git.opendaylight.org/gerrit/#/c/10364/
14:52:34 <liemmn> debugging now...
14:52:45 <hideyuki> gzhao: Yes. a patch for Karaf support for vtn has been already merged. https://git.opendaylight.org/gerrit/#/c/9994/
14:52:56 <edwarnicke> CASP3R: I think they are just awaiting review, could you review them?
14:53:06 <CASP3R> yea i was going to merge it now
14:53:17 <edwarnicke> tbachman: Looking at your features.xml now
14:53:45 <tbachman> edwarnicke: it’s minimal :)
14:54:05 <goldvberg> we in lisp are also waiting for review https://git.opendaylight.org/gerrit/#/c/10364/
14:54:18 <gzhao> edwarnicke: we have representatives from sdni, sfc here
14:55:01 <paulq> #info sfc starting karaf today :)
14:55:02 <gzhao> edwarnicke: and lisp
14:55:10 <gzhao> hideyuki: thanks
14:55:11 <edwarnicke> tbachman: Where are you guys using jackson?
14:55:17 <tbachman> OpFlex
14:55:24 <edwarnicke> I mean in GBP
14:55:50 <edwarnicke> tbachman: I don't see any likely candidates in your feature file...
14:55:54 <tbachman> 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 <gzhao> paulq: great
14:56:01 <tbachman> It’s only a single jar
14:56:08 <tbachman> which is why I was surprised :)
14:56:14 <edwarnicke> Which feature is it used in?
14:56:22 <tbachman> the only one in there ;)
14:56:33 <tbachman> edwarnicke: maybe I’m not following
14:56:35 <edwarnicke> Ah... ofoverlay
14:56:39 <tbachman> yeah
14:56:44 <tbachman> it’s all one feature atm
14:56:52 <tbachman> b/c that’s all we have (Proof Of Concept)
14:57:04 <tbachman> OpFlex code is in there, but we haven’t split these apart
14:57:12 <tbachman> that would be a post-helium thing
14:57:28 <edwarnicke> tbachman: Add these bundles to feature ofoverlay:
14:57:32 <edwarnicke> https://www.irccloud.com/pastebin/46LCJlrZ
14:57:46 <tbachman> edwarnicke: why are these needed here?
14:57:48 <tbachman> (just curious)
14:57:54 <edwarnicke> tbachman: Hang on, let me trim that down a bit
14:58:01 <tbachman> Is this going to be true of any 3rd party dependency?
14:58:11 <edwarnicke> tbachman: Minimal inclusion is the goal
14:58:16 <tbachman> sure
14:58:17 <tbachman> but
14:58:18 <edwarnicke> tbachman: Let me see if I can trim those down
14:58:26 <tbachman> I guess I didn’t understand this entirely
14:58:41 <edwarnicke> tbachman: You want your feature to include *just* the bundles you need to function, *nothing* else
14:58:48 <edwarnicke> Because anything else produces *bloat*
14:58:56 <tbachman> For example, the pom.xml for the project has lots of dependencies
14:59:08 <tbachman> but I didn’t think those were also required in the feature file
14:59:30 <edwarnicke> tbachman: One moment... looking at your code base :)
14:59:35 <tbachman> lol
14:59:52 <tbachman> edwarnicke: it’s more just trying to understand the concept here
14:59:52 <vjanandr> edwarnicke: yes followed the wiki... but not sure what I am missing here..
15:00:05 <tbachman> do we need to repeat every dependency in all the pom files?
15:01:03 <edwarnicke> tbachman: Not everyone, just the ones at runtime... but one moment
15:01:52 <edwarnicke> tbachman: Try just adding these three:
15:01:54 <edwarnicke> https://www.irccloud.com/pastebin/OhMI4sHx
15:02:00 <edwarnicke> And see how that goes
15:02:03 <tbachman> hmmm…. if that’s the case, sounds like a pom file scanner would be useful
15:02:17 <rafat_> #info sdni started Karaf.looks like we will be able to get through the compilation finally :)
15:02:17 <edwarnicke> vjanandr: Hmm... that's odd... because its complaining about missing a class that is explicitely in the archetypes...
15:02:22 <Madhu> hideyuki: 1 comment on the VTN features
15:02:26 <tbachman> edwarnicke: thx
15:02:29 <hideyuki> Madhu: please.
15:02:31 * tbachman is still a bit confused
15:02:42 <Madhu> hideyuki: odl-vtn-manager-neutron is added to vtn-manager-all
15:03:00 <Madhu> hideyuki: by doing that, vtn cannot be part of compatible-with-all in integration project
15:03:05 <Madhu> hideyuki: hope you know that
15:03:21 <Madhu> hideyuki: on the integration project, you would have to create a new compatilbe-with-vtn
15:03:31 <Madhu> and add odl-vtn-manager-all to that.
15:03:45 <edwarnicke> tbachman: I started writing tooling like you describe... but ran out of time
15:03:46 <Madhu> hideyuki: this is because of the conflict it will have with other neutron southbound providers
15:04:00 <tbachman> edwarnicke: no worries — u r a busy fella :)
15:04:11 <hideyuki> Madhu: Oh. That is very awsome comment! Thank you!
15:04:14 <edwarnicke> tbachman: I made things as easy as I could given the time :)
15:04:31 <gzhao> goldvberg: rafat_ vjanandr : May I know the status for your project? thanks
15:04:36 <tbachman> 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 <Madhu> hideyuki: please take a look @ the latest integration features.xml
15:04:51 <Madhu> i added a ovsdb specific neutron implementation compatible feature
15:04:56 <Madhu> which is NOT part of compatible-all
15:05:07 <Madhu> edwarnicke: pls chime in if you have any comments on this.
15:05:08 <gzhao> rafat_: is bgpcep still blocking you
15:05:16 <rafat_> #info rafat for odl-sdni app...we have been able to compile with Karaf successfully
15:05:20 <hideyuki> Madhu: I'm seeing the features.xml.
15:05:24 <rafat_> Yes we are still stuck with bgpcep
15:05:31 <Madhu> 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 <edwarnicke> gzhao: bgpcep is just awaiting review at integration I think
15:05:49 <edwarnicke> Madhu: How can we make that clearer?  I *tried* to, but may have not communicated clearly enough
15:05:54 <gzhao> rafat_: great many thanks
15:06:05 <Madhu> edwarnicke: i think we are doing it now :)
15:06:19 <edwarnicke> CASP3R: Could you review the bgpcep feature because it is blocking sdni
15:06:22 <Madhu> integration project committers can make sure it is taken care of
15:06:31 <CASP3R> there two BGP ones?
15:06:35 <Madhu> CASP3R: has been awesome with reviews... so no concerns there
15:06:36 <gzhao> edwarnicke: that is great, sdni has dependency on bgpcep, that is why I asked.
15:06:40 <edwarnicke> 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 <Madhu> just my 2c to watch out
15:06:54 <edwarnicke> CASP3R: Let me take a look
15:06:59 <edwarnicke> I was helping Heath out yesterday
15:08:38 <edwarnicke> CASP3R: https://git.opendaylight.org/gerrit/#/c/10345/ is the one
15:10:28 <gzhao> vjanandr: how is snbi goging?
15:10:58 <gzhao> goldvberg: did lisp start the process
15:11:21 <goldvberg> gzhao we have a patch waiting for review in integration
15:11:26 <goldvberg> https://git.opendaylight.org/gerrit/#/c/10364/
15:11:59 <gzhao> #action gzhao  need to follow up with projects: defense4all, pluginOC, SNMP4SDN, TTP
15:12:08 <gzhao> goldvberg: cool, thanks
15:12:08 <vjanandr> gzhao: I was following the wiki.. not sure what I am missing.. and I must admit struggling a bit here.. :)
15:12:41 <hideyuki> ghall: Is defense4all in Helium release?
15:13:09 <gzhao> #info lispflowmapping has patch pending review
15:13:43 <gzhao> vjanandr: no problem, just follow it and yell at here for any errors you have
15:14:38 <edwarnicke> vjanandr: Can you push what you have so I can look at it?
15:16:11 <vjanandr> edwarnicke: sure will do..
15:16:36 <edwarnicke> 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 <Madhu> edwarnicke: thinking....
15:17:03 <edwarnicke> 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 <edwarnicke> But I dont' want to leave anyone hanging...
15:18:23 <edwarnicke> Just because my memory is  not at its peak
15:19:11 <tbachman> edwarnicke: for the Nicira extensions
15:19:30 <tbachman> do we reference that feature from the openflowplugin
15:19:34 <tbachman> or from openflowjava?
15:19:42 <edwarnicke> 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 <Madhu> tbachman: niciria extensions is done.
15:20:00 <tbachman> so… I get them from OVSDB?
15:20:02 <edwarnicke> tbachman: Which specific extensions do you need
15:20:03 <Madhu> edwarnicke: just to be clear. i didn't request :)
15:20:04 <edwarnicke> ?
15:20:13 <Madhu> edwarnicke: we didn't have a better option in the short-term.
15:20:22 <tbachman> Tests in error:
15:20:23 <tbachman> 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 <edwarnicke> Madhu: Did I misunderstand?  I had started putting them in OFplugin and you asked me not to
15:20:44 <Madhu> edwarnicke: that is because you said the auto-release will break
15:20:47 <tbachman> I’m wondering if there’s a feature file from openflowjava to reference here
15:20:50 <Madhu> edwarnicke: correct me if am wrong
15:20:53 <edwarnicke> Madhu: Why would autorelease break?
15:21:11 <Madhu> edwarnicke: because there are a few nxm extensions that are defined in ovsdb proejct
15:21:18 <Madhu> and referencing it from openflowplugin
15:21:22 <Madhu> will cause loop.
15:21:23 <edwarnicke> Madhu: Sure... but they should each have a feature of their own
15:21:43 <Madhu> edwarnicke: ah. that won't be very useful for the consumers.
15:21:45 <edwarnicke> 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 <edwarnicke> Madhu: Overinclusion is actually really *nasty* for consumers
15:22:07 <Madhu> edwarnicke: sure... if that is requirement... lets do it
15:22:07 <edwarnicke> Its why we don't do
15:22:12 <edwarnicke> import foo.bar.* anymore
15:22:31 <edwarnicke> Madhu: Honestly... just as happy to leave the nxm extensions where they are
15:22:33 <Madhu> edwarnicke: i have pushed the features in ovsdb with both the extensions defined in openflowplugin and ovsdb projects
15:22:39 <edwarnicke> Madhu: But would request granular features for them
15:22:45 <edwarnicke> Madhu: So folks can avoid overinclusion
15:22:53 <Madhu> edwarnicke: sure. today we have the bare bones :)
15:23:01 <Madhu> edwarnicke: so we are okay at this point
15:23:06 <edwarnicke> Madhu: To be clear: I'm not asking to move the features to OFplugin... :)
15:23:15 * tbachman is confused
15:23:36 <Madhu> edwarnicke: me too ... am not requesting to keeping it in ovsdb :)
15:23:42 <edwarnicke> 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 <Madhu> tbachman: lemme summarize
15:23:46 <edwarnicke> Which is pretty harmless :)
15:24:07 <Madhu> tbachman: we have a few extensions defined in openflowplugin
15:24:11 <edwarnicke> LOL... Madhu does is the why consquential to the what here?
15:24:13 <Madhu> tbachman: and a few in ovsdb project
15:24:25 <edwarnicke> Because as I said... I'm just fine with the 'what' of them being in ovsdb
15:24:47 <tbachman> and by defining the extensions — adding the augmentations in a yang model in your project?
15:24:56 <Madhu> edwarnicke: with sleepless nights... these what & why are greek and latin and i don't know those languages :)
15:25:04 <edwarnicke> LOL
15:25:06 <Madhu> edwarnicke: am perfectly perfectly okay with it being anywhere
15:25:08 <tbachman> <joke></joke>
15:25:10 <Madhu> edwarnicke: just that we need it
15:25:21 <edwarnicke> Madhu: Yep.. the 'what' :)
15:25:46 <Madhu> tbachman: yes. with the awesome open flow extensibility feature.. we can define it anywhere
15:25:52 <tbachman> :)
15:25:59 <edwarnicke> 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 <Madhu> tbachman: and can dynamically add it to the model tree
15:26:13 <edwarnicke> tbachman: Sorry for the confusion
15:26:16 <Madhu> edwarnicke: yes. we are in consensus :)
15:26:18 <edwarnicke> tbachman: Which extensions are you using?
15:26:20 <tbachman> edwarnicke: no worries
15:26:25 <tbachman> I’d have to check
15:26:29 <tbachman> readams created them
15:26:40 <Madhu> tbachman: all you need at this point is
15:26:43 <edwarnicke> Madhu: <joke>#info Madhu and edwarnicke have agreed to disagree about agreeing</joke>
15:27:06 <Madhu> edwarnicke: #info and I approve the above joke
15:27:31 <Madhu> tbachman: please take a look @ the integration project
15:27:43 <Madhu> we added the feature named  odl-openflow-nxm-extensions
15:27:44 <tbachman> Madhu: will do
15:27:45 <tbachman> thx
15:27:52 <gzhao> #info 5 projects change status from not started to started this morning: GBP, Lisp, SDNi, SNBI and SFC
15:27:58 <Madhu> tbachman: it also has the dependency to inclue
15:28:12 <Madhu> that dependency should ideally go out to its own project during lithium
15:28:27 <Madhu> we are keeping it in ovsdb for now for release convience (as I thought) :)
15:28:36 <tbachman> :)
15:29:27 <edwarnicke> CASP3R: How goes the bgpcep review?
15:29:35 <edwarnicke> CASP3R: Asking so we can unstick SNDi
15:29:39 <CASP3R> on a meeting
15:29:42 <edwarnicke> vjanandr: How are things with you?
15:29:46 <edwarnicke> CASP3R: ACK
15:31:11 <edwarnicke> Madhu: How many extensions are there now?
15:31:21 <vjanandr> edwarnicke: trying few things.. I will push the code..
15:32:48 <edwarnicke> vjanandr: Cool... as long as you aren't blocking on me :)
15:35:22 <tbachman> hmmm
15:35:32 <tbachman> so…. I should expect to see something in a yang file in our project
15:35:40 <tbachman> that augments an existing OF yang model
15:35:44 <edwarnicke> 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 <tbachman> in order for there to be a n extension
15:36:09 <tbachman> If that’s the case — I’m not seeing that in any of our yang models
15:36:12 <edwarnicke> I also recommend *against* treating -all as a top level feature instead of an index for the same reason
15:37:03 <tbachman> 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 <edwarnicke> tbachman: You aren't... I was refering to the growing habit of listing <project>-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 <edwarnicke> tbachman: Nope, you aren't :)
15:38:01 <tbachman> :)
15:38:02 <tbachman> thx
15:38:35 <edwarnicke> tbachman: Do you have extensions in GBP project?
15:38:51 <tbachman> edwarnicke: I know that (somehow) we’re using them
15:39:08 <tbachman> I just don’t see anything in any of our yang models that augment an existing openflowplugin yang model
15:39:11 <tbachman> (or openflowjava)
15:39:19 <Madhu> tbachman: afaik
15:39:22 <edwarnicke> 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 <Madhu> tbachman: GBP is using the extensions defined in openflowplugin
15:39:34 <tbachman> ah
15:39:39 <Madhu> tbachman: you have 2 choices now
15:39:41 <edwarnicke> tbachman: Which extensions are you using?
15:39:48 <tbachman> so, that’s as edwarnicke said - there are some in the plugin, and some in OVSDB
15:39:50 <Madhu> tbachman: either you can use the bundles directly in your feature
15:39:51 <tbachman> got it
15:40:01 <edwarnicke> tbachman: Which ones though, by name?
15:40:05 <Madhu> tbachman: or include the feature.
15:40:15 <Madhu> tbachman: it depends on the features u use...
15:40:15 <tbachman> edwarnicke: I’d have to go code-diving
15:40:22 <tbachman> This was readams’ portion
15:40:25 <tbachman> give me a sec...
15:40:29 <Madhu> tbachman: in GBP.. just look @ the flowutils.java :)
15:40:31 <CASP3R> edwarnicke this the BGP one right https://git.opendaylight.org/gerrit/#/c/10345/
15:40:41 <tbachman> yeah
15:40:46 <edwarnicke> CASP3R: yes
15:40:48 <Madhu> tbachman: that is the place where readams added all the extension usage
15:40:54 <tbachman> right
15:40:56 <CASP3R> Looking into now
15:41:06 <edwarnicke> Madhu: Could you please provide granular features for individual extensions?
15:41:12 <edwarnicke> So we don't wind up with a
15:41:19 <edwarnicke> import foo.bar.*; problem
15:41:27 <Madhu> edwarnicke: individual extension feature is not needed :) they can use the bundle directly :)
15:41:43 <edwarnicke> Ah...OK... they are single bundles then?
15:41:48 <Madhu> edwarnicke: yep.
15:41:49 * edwarnicke has fallen behind :(
15:41:59 <edwarnicke> Madhu: What other features do they need to work?
15:42:18 <tbachman> it would only be the ones with “extension” in the import, right?
15:42:21 <tbachman> Not the “match”
15:42:45 <Madhu> tbachman: yes.
15:42:50 <tbachman> http://pastebin.com/RJpuAtCm
15:42:55 <tbachman> has the match in there too, fwiw
15:43:09 <Madhu> tbachman yes.
15:43:30 <Madhu> tbachman: but think about this... if u want to selectively import the bundles as your dependencies...
15:43:48 <Madhu> then you have to follow the work I did in ovsdb
15:43:56 <Madhu> you can "reuse" it :)
15:44:03 <tbachman> :)
15:44:12 * tbachman knows how to make many new bugs with cut-and-paste
15:44:26 <Madhu> tbachman: don't cut-paste :) just get inspired
15:44:29 <tbachman> lol
15:44:38 <Madhu> tbachman: it has all the dependencies that you are interested it
15:44:44 <tbachman> I’m wondering
15:44:44 <Madhu> you can just selectively pick what you like
15:44:52 <Madhu> tbachman: but for a PoC.. i would say
15:44:55 <Madhu> just include the feature
15:44:59 <Madhu> and see if that works for u
15:45:00 <tbachman> the interest here is to be able to have just one project pull them in
15:45:06 <tbachman> Madhu: was going to the same place :)
15:45:07 <tbachman> lol
15:45:20 <tbachman> I can see in a project that would co-exist with other protocols
15:45:23 <Madhu> tbachman: try that out first. and if that works, then you should do what edwarnicke suggested
15:45:28 <tbachman> that making it a separate feature makes sense
15:45:36 <tbachman> but this is a one-trick-pony atm
15:45:51 <Madhu> tbachman: yes.. it is too last minute and hence we are taking this approach.
15:46:05 <tbachman> k
15:46:11 <tbachman> Madhu: edwarnicke thx for your help!
15:46:26 <abhijitkumbhare> 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 <Madhu> 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 <Madhu> abhijitkumbhare: just because of the fact that it is vendor agnostic
15:47:38 <Madhu> its better to have a project
15:47:44 <Madhu> called nxm-extensions
15:47:46 <Madhu> and place it there
15:47:57 <Madhu> and all of us can use it
15:48:12 <edwarnicke> Madhu: Lithium :)
15:48:15 <Madhu> abhijitkumbhare: do u agree ?
15:48:21 <Madhu> edwarnicke: ofcourse. lol
15:48:47 <edwarnicke> <joke> Sorry, <joke>Lithium ;)</joke></joke>
15:49:02 <tbachman> embedded jokes! :
15:49:03 <tbachman> :)
15:49:04 <Madhu> edwarnicke: is it a joke ?
15:49:13 <tbachman> SEO joke
15:49:21 <Madhu> i thought it is seriously serious :)
15:49:22 <abhijitkumbhare> 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 <edwarnicke> Madhu: It was a jocular statement... but not quite a joke
15:49:38 <edwarnicke> The <joke></joke></joke>
15:49:51 <edwarnicke> Was joking about needing to mark it a joke when it was clearly heard properly :)
15:49:52 <Madhu> oh god. a joke on a joke
15:50:29 <Madhu> abhijitkumbhare: good point indeed.
15:50:41 <Madhu> abhijitkumbhare: so we are talking about openflow-extensions project :)
15:50:49 <abhijitkumbhare> Madhu - just have not decided (what my thought on that is)
15:50:56 <Madhu> where nxm and other "open" extensions will play a role :)
15:50:58 <abhijitkumbhare> Madhu: yes :)
15:51:14 <Madhu> abhijitkumbhare: so strange we call it "open" extension.
15:51:26 <Madhu> but it is a fact
15:51:40 <abhijitkumbhare> when its a nicira extension ? :)
15:51:48 <edwarnicke> 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 <tbachman> hmmm…. so, are the extensions currently exported as a feature in the openflowplugin?
15:52:10 <Madhu> tbachman: extensions support is
15:52:15 <Madhu> tbachman: not nicira extension
15:52:27 <tbachman> which feature?
15:52:29 <Madhu> abhijitkumbhare: edwarnicke yes :)
15:52:39 <Madhu> tbachman: features-openflowplugin
15:52:49 <tbachman> :)
15:52:52 <Madhu> tbachman: according to me that is absolutely the right thing to do
15:52:59 <tbachman> Madhu: thx
15:53:02 <tbachman> makes sense to me
15:53:04 <Madhu> extensions support is fully owned by openflowplugin
15:53:08 <Madhu> individual extensions are not.
15:53:30 <edwarnicke> Madhu: Yes, the point is to not require the extensions to live in openflowplugin
15:53:36 <edwarnicke> Madhu: Or even in ODL frankly
15:53:46 <Madhu> edwarnicke: absolutely absolutely :)
15:54:35 <abhijitkumbhare> edwarnicke Madhu: agreed on that
15:55:06 <Madhu> abhijitkumbhare: edwarnicke i am really really trying hard not to piss off anyone by defining features for nxm :)
15:55:20 <Madhu> just that we need it ASAP before M5 and am defining them for everyone's benefit
15:55:28 <Madhu> if you guys have better option to handle it am all ears
15:56:02 <edwarnicke> Madhu: I am not pissed off :)  If abhijitkumbhare has a concern mostly I would like to understand it :)
15:57:30 <abhijitkumbhare> edwarnicke Madhu: I don’t have a concern - I am still debating with myself - whether it makes sense to have all the openflow extensions within ODL in one place - into a project called openflow-extensions -
15:57:31 <Madhu> edwarnicke: thanks. abhijitkumbhare please let us know
15:57:48 <Madhu> abhijitkumbhare: that would be a great start if u ask me
15:57:51 <abhijitkumbhare> But as I said - its a topic for Lithium
15:57:51 <edwarnicke> abhijitkumbhare: That's a totally valid place to be
15:57:51 * tbachman is trying to find features-openflowplugin
15:58:05 <tbachman> abhijitkumbhare: will you be at the dev summit?
15:58:07 <edwarnicke> I have a lot of stuff myself where I don't yet have an opinon, but I can recognize that there are questions to explore
15:58:23 * Madhu points him to ovsdb features/of-extensions project :)
15:58:23 <edwarnicke> tbachman:
15:58:25 <abhijitkumbhare> Yes tbachman (but the first day only)
15:58:26 <edwarnicke> https://www.irccloud.com/pastebin/f3PvIGnA
15:58:56 <tbachman> that’s for the pom — do I need anything in the features file?
15:58:59 <tbachman> (thx btw)
15:59:11 <edwarnicke> tbachman: One moment
15:59:23 <edwarnicke> <repository>mvn:org.opendaylight.ovsdb/features-openflow-nxm/0.0.3-SNAPSHOT/xml/features</repository>
15:59:41 <edwarnicke> tbachman: Are you using *just* the SB plugin, or also things like topology etc?
15:59:43 <tbachman> edwarnicke: thx!
15:59:54 <tbachman> hmmm.....
15:59:58 <tbachman> we use stuff from the controller
16:00:02 <tbachman> for example, we augment node
16:00:15 <tbachman> but from the plugin
16:00:16 <tbachman> just the sB
16:00:17 <tbachman> SB
16:00:19 <tbachman> for flow programming
16:00:29 <edwarnicke> OK... one moment
16:00:31 <tbachman> flow-capable-node
16:01:02 <edwarnicke> This is the feature for just the SB plugin: <feature version="${project.version}">odl-openflowplugin-southbound</feature>
16:01:11 <abhijitkumbhare> I need to be going off (for now) - will read up the conversation later
16:01:20 <edwarnicke> tbachman: Ah... so, you have two choices
16:01:29 <edwarnicke> Actually... you probably don't :(
16:01:44 <edwarnicke> It sounds like you are using the reporting of inventory to the model, right??
16:01:46 * tbachman waits 10 seconds to see if it changes again
16:01:55 <edwarnicke> You guys are looking up stats in the datatree I presume?
16:01:58 <tbachman> nope
16:02:11 <tbachman> just a sec...
16:02:39 <edwarnicke> tbachman: So, here's the short answer
16:02:41 <tbachman> we are adding a location to the node
16:02:46 <edwarnicke> Openflowplugin provides two features:
16:02:56 <edwarnicke> <feature version="${project.version}">odl-openflowplugin-southbound</feature> - just the SB plugin
16:03:14 <edwarnicke> <feature version="${project.version}">odl-openflowplugin-flow-services</feature> - the SB plugin plus the flow services (stats reporting, topology, etc)
16:03:36 <edwarnicke> (the second one isn't really fully originating in OFplugin... it just wraps in flow-services from controller)
16:03:40 <edwarnicke> tbachman: With me so far?
16:03:43 <tbachman> yup
16:03:54 <tbachman> hmmm....
16:03:58 <tbachman> I think I see where you’re going
16:04:04 <tbachman> I *could* just do flow-services
16:04:04 <tbachman> but
16:04:12 <tbachman> there’s a but somewhere, am guessing ;)
16:05:17 <edwarnicke> tbachman: Doesn't have to be a but
16:05:23 <tbachman> ah
16:05:29 <tbachman> so…. just flow-services
16:05:29 <edwarnicke> tbachman: Just trying to sort out the right fit for you :)
16:05:34 <edwarnicke> tbachman: So you could do the following
16:05:38 * tbachman loks to see if that’s a feature by itself
16:05:46 <edwarnicke> tbachman: Use <feature version="${project.version}">odl-openflowplugin-flow-services</feature> for now
16:05:51 <tbachman> k
16:05:54 <tbachman> I’ll iterate
16:05:58 <tbachman> I think I’ve got the concept
16:05:59 <edwarnicke> tbachman: Put in a TODO to look into it (and/or file a bug)
16:06:01 <tbachman> which is the important part
16:06:03 <tbachman> yeah
16:06:04 <tbachman> I mean
16:06:13 <tbachman> we’ll definitely want this to look diffrent for lithium
16:06:19 <edwarnicke> tbachman: Sure
16:06:20 <tbachman> but this will do for Helium
16:06:31 <edwarnicke> tbachman: And there's actually some flex in Helium too if you'd like
16:06:32 <tbachman> edwarnicke: Madhu: thx guys so much for ur help!!!!
16:06:37 <tbachman> ?
16:07:47 <Madhu> edwarnicke: on this topic.. wanted to get your opinion and also with abhijitkumbhare
16:08:01 <Madhu> was thinking if we should bring in the legacy open flow plugin to the integration karaf
16:08:23 <Madhu> if we do that.. then the openflowplugin and openflowjava must go out of all and to the compatible one. which I hate to see.
16:08:31 <Madhu> what is your opinion guys ?
16:08:49 <Madhu> am not spending time on bringing that plugin in... but willing to hear your feedback edwarnicke & abhijitkumbhare
16:10:18 <edwarnicke> Madhu: It would splinter things pretty badly, and leave us with no out of the box openflow support in compatibile-with-all
16:10:49 <Madhu> edwarnicke: that is my concern too.
16:11:16 <CASP3R_> I been trying to word this right way but here go   "What is the benefit to doing it, IE what can't the openflowplugin do that the old one can"
16:11:35 <CASP3R_> I understand they have different API calls and some people maybe still using these
16:11:38 <Madhu> CASP3R_: very good point.
16:11:59 <Madhu> CASP3R_: API is not the concern. thanks to edwarnicke we have sal-compatibliity
16:12:16 <Madhu> CASP3R_: the question was mostly for the apps that expect a certain behaviour
16:12:42 <CASP3R_> Yea i just wasn't sure if there was any limitation with the sal-compativlity
16:12:43 <Madhu> CASP3R_: for example. the ovsdb-openstack support has 2 modes of operation (1 for legacy plugin) and the other for non-legacy
16:13:13 <Madhu> CASP3R_: the ovsdb-openstack plugin didn't use the sal-compatibility at all for testing.
16:13:33 <Madhu> CASP3R_: and if am not wrong so is VTN. hideyuki can u pls keep me honest here ?
16:13:52 <Madhu> let me be clear.. i don't want to see this happening.
16:14:01 <hideyuki> Madhu: Hi!
16:14:02 <Madhu> but it is more of a question on what shall we do to mitigate ?
16:14:14 <edwarnicke> Madhu: We worked through all of that working with the adaptors though in the switchover though, correct?
16:14:22 <Madhu> hideyuki: the question : do u see a need to have the old legacy open flow plugin in place for karaf ?
16:14:28 <edwarnicke> Madhu: Mitigate what?
16:14:53 <Madhu> edwarnicke: yes. but i haven't tested it so the ovsdb-openstack code still has legacy assumptions for OF10 mode.
16:15:08 <Madhu> edwarnicke: am just trying to explore :)
16:15:12 <hideyuki> Madhu: My answer is No.
16:15:13 <edwarnicke> Madhu: We explicitely asked you guys to repeatedly over many months
16:15:42 <Madhu> edwarnicke: ?
16:15:42 <edwarnicke> Madhu: As part of the switchover
16:15:50 <hideyuki> Madhu: If new openflow plugin works fine for OF1.0 switches, VTN does not need the old openfolow plugin.
16:16:02 <Madhu> hideyuki: thanks for the confirmation
16:16:41 <Madhu> edwarnicke: i will take you through the current issue that we have. maybe we can find a better way out.
16:17:08 <Madhu> edwarnicke: how would u feel if we don't touch the compatible-with-all
16:17:17 <Madhu> but also add a feature-legcy-openflow-plugin
16:17:20 <Madhu> and keep it handy
16:17:24 <Madhu> if someone really wants to use it
16:17:27 <edwarnicke> Madhu: It would no longer be true
16:17:35 <edwarnicke> And it would break testing
16:18:04 <edwarnicke> Madhu: Is the only issue here that you didn't test your legacy stuff during the three month period from declaration of switch over to switchover?
16:18:20 <Madhu> edwarnicke: is there a declaration like that ?
16:18:28 <Madhu> edwarnicke: seriously i didn't know it happened.
16:18:34 <Madhu> edwarnicke: same communication over-load
16:19:27 <Madhu> edwarnicke: would you mind pointing any such thread ?
16:20:41 <Madhu> CASP3R_: u have any communication on this on the list that i missed ?
16:22:31 * CASP3R_ stands on the sideline
16:23:36 <edwarnicke> Madhu: Look at both the openflowplugin and controller release plans
16:23:37 <CASP3R_> I wasn't around much 3 months ago to remember but i do know there was alot of work around sal-compativlity (as it ever 2nd day it was breaking CSIT)
16:23:45 <edwarnicke> I can dig up the emails that pointed that out directly to ovsdb
16:24:02 <edwarnicke> They were sent out pre-M2 because of the switchover being planned for M3
16:24:03 <edwarnicke> M2
16:24:50 <tbachman> guys — not to break up the fun
16:24:55 <tbachman> but — I still have a hurdle
16:25:16 <tbachman> Tho since we’re approaching 2hrs, am fine with “the Karaf Happy Hour is closed"
16:25:30 * tbachman watches bartender kick him out the door
16:25:43 <Madhu> edwarnicke: yes. it is about switchover default use of oepnflowplugin
16:26:19 <Madhu> edwarnicke: and deprecation of legacy plugin.
16:26:34 <Madhu> edwarnicke: i was hoping that deprecation means.. supported. but will be removed eventually
16:26:42 <Madhu> edwarnicke: did i get that wrong ?
16:30:18 <CASP3R_> ls
16:30:40 <Madhu> CASP3R_: <no file or directory>
16:30:54 <CASP3R_> :)
16:31:08 <tbachman> stale file or directory
16:32:21 <tbachman> fwiw
16:32:26 <tbachman> it appears that features-openflow-nxm isn’t sufficient
16:32:36 <tbachman> b/c I still get this
16:32:36 <tbachman> Tests in error:
16:32:37 <tbachman> 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)"
16:33:13 <tbachman> There’s got to be another one
16:33:16 <tbachman> I’ll track it down
16:35:40 <edwarnicke> #endmeeting