According to our discussion yesterday, config knobs will be defined in .cfg files and in yang (same names to be used in both places)
1. Values defined .cfg files will be the Day 0 configuration. These values will be used initially. 2. If the admin wants to change it at run time, then it can be done using REST APIs. These values will be stored in datastore but not written into the .cfg file. The dynamic changes will not trigger a bundle restart. 3. The REST API has the advantage that the values can be configured across the cluster and persisted across controller restarts. 4. Upon controller restart, if values are configured in MDSAL datastore, then that takes precedence over the .cfg file. Hope I have covered all the points. Thanks, Hema From: [email protected] [mailto:[email protected]] On Behalf Of Anil Vishnoi Sent: 18 January 2017 08:11 To: Shuva Kar <[email protected]> Cc: openflowplugin-dev <[email protected]> Subject: Re: [openflowplugin-dev] User Configuration Knobs 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]<mailto:[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
