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 >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
