Thanks for starting the thread shuva.

I see two problems with the way we expose the config currently

(1) Options in .cfg files are not named same as in .yang (e.g
skip-table-features
(.cfg) & switch-features-mandatory (.yang)).
(2) We only have a set of options in .cfg file from the yang file, it
actually creates a confusion for user as they think that these are two
different set of options and user is not sure which one to use to make the
desired config.

I think we should narrow down to a clear contract about the config option
plugin should expose for user and clearly mention what all options are
supported at runtime. I would like to put a proposal for discussion

(1) All the config that is present in the yang, should be present in the
.cfg file as well (with an exact same name), we should take the name that
is present in the yang file ( to avoid any api change, assuming we will
push these changes to boron).
(2) We should clearly add a description to both .yang and .cfg file on
which parameter can be configured at run time.
(3) We should use the .cfg file to override the default values in yang.
(4) if user want to modify the parameters at run time, they should only use
restconf mechanism. We should internally write a listener that should
listen to the yang model and also set the reload=none in blueprint config,
so that bundle does not restart whenever user change the config.

Alternate option for (4) is to say that user should use .cfg file for
making the run-time changes, but I think that might not work better in the
clustered environment, so from clustered setup perspective restconf is a
better option.

Let me know your thoughts?

Thanks
Anil

On Thu, Jan 12, 2017 at 10:13 PM, Shuva Kar <[email protected]>
wrote:

> Hello devs,
>
> As a part of Bug-6890, we addressed moving some(7/13) of the configuration
> parameters from *yang(openflow-provider-config.yang) to cfg file
> (openflowplugin.cfg),*
>
> *The original list of parameters includes:*
>
> *1.rpc-requests-quota //default 20000 **
> 2.switch-features-mandatory //default false **
> 3.global-notification-quota //default 64000 ***
> 4.is-statistics-polling-off //default false
> 5.is-statistics-rpc-enabled // default false
> 6.barrier-interval-timeout-limit //default 500
> 7.barrier-count-limit //default 25600
> 8.echo-reply-timeout //default 2000*9.thread-pool-min-threads //default 1 **
> 10.thread-pool-max-threads // default 32000 **
> 11.thread-pool-timeout //default 60 ***
> 12.notification-flow-removed-off //default false
> 13.skip-table-features //default true
>
> Out of these* 7 parameters* have been moved to the cfg file and* these 
> include*
>
> enable-flow-removed-notification=true
> skip-table-features=true
> is-statistics-rpc-enabled=false
> barrier-interval-timeout-limit=500
> barrier-count-limit=25600
> echo-reply-timeout=2000
> is-statistics-polling-on=true
>
> and the ones [****] have not been moved since changing either threadpool size 
> or threadpool timeout is something that will have deep and *domino *ing 
> effects on the performance of the ofplugin.
>
> But as discussed in the call yesterday, as these have been exposed in yang 
> and therefore in restconf we need to either document these or prevent user 
> from modifying or better still have it only for debug/tuning options.
>
> This email aims to provide the basis for a discussion to start on how best to 
> have user config knobs.
>
> Lets have a good discussion :)
>
> PPS: Sorry for the previous blank email, thanks to my system for being 
> mischievous :P
>
> Br,shuva
>



-- 
Thanks
Anil
_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to