If written to the datastore, yes the clustered-app-config will restart the container. This allows for dynamic changes.
On Fri, Aug 5, 2016 at 5:04 PM, Anil Vishnoi <[email protected]> wrote: > I believe, if user will change the value of this flag after controller > boot, blueprint will restart the openflowplugin bundle, is that okay ? > > Tom, correct me if i am wrong. > > On Fri, Aug 5, 2016 at 9:05 AM, Shuva Jyoti Kar < > [email protected]> wrote: > >> 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]] >> *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/openflowplug >> in-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] >> aylight.org >> *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]>; >> [email protected] >> *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
