Thanks for the summary Hema, this morning I could not attend the call but this is useful info. Question: do we plan to put also in .cfg those knobs that are only in yang today, like for example the idle-flow mode I have tested recently.
BR/Luis > On Jan 19, 2017, at 8:31 PM, Hema Gopalkrishnan > <[email protected]> wrote: > > 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
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
