You don't see this exception, because table features are off, so it's not really a solution for the problem mentioned in the bug 4473. But regardless to 4473, if dependent projects are okay, we should disable the table features.
On Sun, Aug 7, 2016 at 11:09 PM, Shuva Jyoti Kar < [email protected]> wrote: > with table-features switched off , the error messages mentioned in > https://bugs.opendaylight.org/show_bug.cgi?id=4473 are not logged. So we > might need to switch it off. > > *From:* Shuva Jyoti Kar > *Sent:* Friday, August 05, 2016 9:35 PM > *To:* 'Andrej Leitner'; Anil Vishnoi; Jozef Bacigál; Tom Pantelis; > [email protected] > *Cc:* [email protected]; [email protected] > *Subject:* RE: Patch for tuning table features > > > > Have updated the patch with the required changes. Have removed the cfg > file and the “managed-properties” tag in openflowplugin.xml , since its > pointing to doing the same task of configuration in 2 different ways – > that can lead to confusion. > > > > We can use PUT @ http://localhost:8181/restconf/config/openflow- > provider-config:openflow-provider-config/ with the following > configuration > > > > { > > "openflow-provider-config": { > > "skip-table-features": true > > } > > } > > > > To turn table features off and similarly for other properties. > > *From:* Andrej Leitner [mailto:[email protected] > <[email protected]>] > *Sent:* Thursday, August 04, 2016 1:12 PM > *To:* Shuva Jyoti Kar; Anil Vishnoi; Jozef Bacigál; Tom Pantelis; > [email protected] > *Cc:* [email protected]; [email protected] > *Subject:* Re: Patch for tuning table features > > > > FYI, discussion about how to deal with config parameters continues also > here: > > https://git.opendaylight.org/gerrit/#/c/42821/1/openflowplugin-blueprint- > config/src/main/resources/initial/openflowplugin.cfg > > > > <https://git.opendaylight.org/gerrit/#/c/42821/1/openflowplugin-blueprint-config/src/main/resources/initial/openflowplugin.cfg> > > > ------------------------------ > > *From:* Shuva Jyoti Kar <[email protected]> > *Sent:* Wednesday, August 3, 2016 9:41 AM > *To:* Anil Vishnoi; Jozef Bacigál > *Cc:* Tom Pantelis; [email protected]; > [email protected]; [email protected] > *Subject:* Re: [openflowplugin-dev] Patch for tuning table features > > > > I have seen it one time . > > > > *From:* Anil Vishnoi [mailto:[email protected] <[email protected]>] > > *Sent:* Wednesday, August 03, 2016 1:10 PM > *To:* Jozef Bacigál > *Cc:* Abhijit Kumbhare; [email protected]; Tom > Pantelis; Muthukumaran K; Shuva Jyoti Kar; Luis Gomez; > [email protected]; [email protected] > *Subject:* Re: Patch for tuning table features > > > > Quick question Jozef, do we periodically fetch the table features ? In > helium design we just fetch is once only. So as far as lithium plugin > fetches it once, i don;t really see any performance impact as such (except > switch connection time data processing). > > > > On Wed, Aug 3, 2016 at 12:02 AM, Jozef Bacigál < > [email protected]> wrote: > > Hi guys, > > > > Sorry I wasn’t here for two days, but first thing the patch seems good. > Second thing I see no problem when the table features stay switched ON. > Before the changes the table features were inside the tables and with each > table we always loaded full features. Now are the features on the same > level as table so performance in boron get better. It would be nice to have > some performance test with ON/OFF table features with this patch set. > > > > Jozef > > > > *From:* Abhijit Kumbhare [mailto:[email protected]] > *Sent:* Wednesday, August 3, 2016 7:37 AM > *To:* Anil Vishnoi <[email protected]>; openflowplugin-dev@lists. > opendaylight.org > *Cc:* Tom Pantelis <[email protected]>; Muthukumaran K < > [email protected]>; Shuva Jyoti Kar < > [email protected]>; Jozef Bacigál <[email protected]>; > Luis Gomez <[email protected]>; [email protected]; > [email protected] > > > *Subject:* Re: Patch for tuning table features > > > > Yes - we should reach out to DIDM & the NIC project - but I want to also > discuss this in this week's meeting. > > > > I have added the OpenFlow Plugin mailing list - as well as DIDM & NIC - so > they can be aware of this discussion. If I remember right we had also > discussed this earlier - don't remember what we had concluded then. > > > > > > On Tue, Aug 2, 2016 at 10:31 PM, Anil Vishnoi <[email protected]> > wrote: > > > > > > On Tue, Aug 2, 2016 at 10:04 PM, Tom Pantelis <[email protected]> > wrote: > > So you have some apps that need table-features enabled but other apps that > need it off? That sounds like a deployment headache - what if an end user > has installed an app that needs it on and also an app that needs it off? > What happens to an app if the setting isn't what it needs? > > It's moreover like, some apps need it, but apps who don't need it, would > *prefer* to disable it for performance reason. So if it comes to the > situation where one app need table features, then other app will have to > live with it. > > But yes, it's still an deployment options, and we were thinking an easy > way for doing that. > > > > > > Regardless, this seems like a deployment option for the end user or > integrator, ie let the user decide what to set it to rather than apps > trying to set it automatically on install and possibly stomping over one > another. So if a user installs DIDM, document that they must enable > table-features. > > This is also reasonable option, but not sure if didm and nic projects are > okay with it or not. This might add some work on their plate to fix their > intergration/csit jobs etc. > > > > Abhijit, do you think it make sense to reach out to DIDM/NIC project? > > > > On Wed, Aug 3, 2016 at 12:29 AM, Muthukumaran K < > [email protected]> wrote: > > So, assuming that a set of projects require default-value for a config > param (table-features in this case) to be true, they would have use what > comes out of box (assuming that XML what we ship via features.xml sets the > value to true). > > Then another set of projects want to flip – they stop the whole karaf > container, edit this XML and restart. Or they can edit the XML file on fly ? > > > > Clarity of this sequence may be useful for how test automation runs CSIT – > a set of Test suites which require the value to be true (in this example, > DIDM, NIC) and another set of test suites which require this value to be > false (everything else other than NIC or DIDM) > > > > Regards > > Muthu > > > > > > *From:* Tom Pantelis [mailto:[email protected]] > *Sent:* Wednesday, August 03, 2016 9:46 AM > *To:* Anil Vishnoi > *Cc:* Abhijit Kumbhare; Shuva Jyoti Kar; [email protected]; > Muthukumaran K > > > *Subject:* Re: Patch for tuning table features > > > > If using clustered-app-config, the default value can be set via an > external XML file that could be shipped via a features.xml. See > https://wiki.opendaylight.org/view/Using_Blueprint#Using_the_Datastore > > > > On Tue, Aug 2, 2016 at 6:08 PM, Anil Vishnoi <[email protected]> > wrote: > > I think two project had dependent (DIDM and NIC) on the table > features. So if plugin will disable it now, both the project will > break. So if we want to disable table features, we need to provide > some solution on how these project can enable it. > > Given that all the config nobs are present in data store, didm/nic > project can overwrite the default value to false, but that will > restart the openflowplugin model, which i think should be fine. > > Tom, do you have any other thoughts on how projects can set value of > config nob exposed by dependent projects? > > On Tue, Aug 2, 2016 at 2:25 PM, Abhijit Kumbhare <[email protected]> > wrote: > > Added Jozef. Since it is Jozef's patch and you are now a committer - you > can > > review/merge it :) > > > > On Mon, Aug 1, 2016 at 11:57 PM, Shuva Jyoti Kar > > <[email protected]> wrote: > >> > >> Sure, sounds good. Can you please review the patch and merge it then ? > >> > >> > >> > >> Thanks > >> > >> Shuva > >> > >> > >> > >> From: Abhijit Kumbhare [mailto:[email protected]] > >> Sent: Tuesday, August 02, 2016 12:25 PM > >> > >> > >> To: Shuva Jyoti Kar > >> Cc: Muthukumaran K; Anil Vishnoi > >> Subject: Re: Patch for tuning table features > >> > >> > >> > >> We should ask DIDM to turn it on if and when they need it. > >> > >> On Monday, August 1, 2016, Shuva Jyoti Kar < > [email protected]> > >> wrote: > >> > >> I do see your point Abhjit. The spec says “If it wishes to understand > the > >> size, types, and order in which tables are consulted, the controller > >> > >> sends a OFPMP_TABLE_FEATURES multipart request (see A.3.5.5)”. Hence it > >> would be optional. Am I correct ? > >> > >> > >> > >> But if we turn it off by , will any projects have a problem ? I remember > >> DIDM having a dependency. > >> > >> The current status that exists for the He and Li designs are: > >> > >> > >> > >> Master > >> > >> > >> > >> He-design: turned on by default, can be turned off > >> > >> Li-design :mandatory now[my patch will make it configurable] > >> > >> > >> > >> Stable/Be > >> > >> > >> > >> He-design: turned on by default, can be turned off > >> > >> Li-design: turned off by default as per > >> https://git.opendaylight.org/gerrit/#/c/36506/4 > >> > >> > >> > >> I do see a point it making it off by default. Do let me know if I am > >> missing something > >> > >> > >> > >> Thanks > >> > >> Shuva > >> > >> > >> > >> From: Abhijit Kumbhare [mailto:[email protected]] > >> Sent: Tuesday, August 02, 2016 5:20 AM > >> To: Shuva Jyoti Kar > >> Cc: Muthukumaran K; Anil Vishnoi > >> Subject: Re: Patch for tuning table features > >> > >> > >> > >> The spec does not say that the table features HAS to be used. I think we > >> should turn it off on both the He and the Li designs to keep consistent > >> assuming it is causing enough performance problems. > >> > >> > >> > >> On Sat, Jul 30, 2016 at 7:47 PM, Shuva Jyoti Kar > >> <[email protected]> wrote: > >> > >> Absolutely Muthu ,nothing else. Aligining with the spec its been turned > on > >> but can be turned off in a manner that aligns with the implementation > on the > >> He plugin as well. > >> > >> On Sun, Jul 31, 2016 at 2:53 AM, Muthukumaran K > >> <[email protected]> wrote: > >> > >> > >> > >> It was kept on just to be in alignment with spec and also with He > plugin’s > >> config > >> > >> > >> > >> Anything else Shuva ? > >> > >> > >> > >> Regards > >> > >> Muthu > >> > >> > >> > >> > >> > >> From: Abhijit Kumbhare [mailto:[email protected]] > >> Sent: Sunday, July 31, 2016 2:52 AM > >> To: Shuva Jyoti Kar > >> Cc: Anil Vishnoi; Muthukumaran K > >> Subject: Re: Patch for tuning table features > >> > >> > >> > >> Then shouldn't it be off by default if OVS 2.4 is sending a lot of data > >> and performance suffers? > >> > >> On Saturday, July 30, 2016, Shuva Jyoti Kar < > [email protected]> > >> wrote: > >> > >> Hi Anil, Abhijit, > >> > >> > >> > >> I have pushed a patch for turning table-features ON/OFF with the > >> li-plugin. By default it is on, but can be switched off. > >> > >> > >> > >> https://git.opendaylight.org/gerrit/#/c/42821/1 > >> > >> > >> > >> We need this fix since by default ovs2.4 sends quite a huge amount of > data > >> for each switch connected. > >> > >> > >> > >> Could you please review the change and let me know your comments. > >> > >> > >> > >> Thanks > >> > >> Shuva > >> > >> > > > > > > > > -- > Thanks > Anil > > > > > > > > > > -- > > Thanks > > Anil > > > > Jozef*Bacigál* > > Software Engineer > > > Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia > R&D centrum / Janka Kráľa 9 / 974 01 Banská Bystrica / Slovakia > +421 908 766 972 / [email protected] > reception: +421 2 206 65 114 / www.pantheon.sk > > [image: logo] > > > > > > > > -- > > Thanks > > Anil > > Andrej*Leitner* > > Software Developer > > > Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia > R&D centrum / Janka Kráľa 9 / 974 01 Banská Bystrica / Slovakia > / [email protected] > reception: +421 2 206 65 114 / www.pantheon.sk > > [image: logo] > > > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
