About: 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.
I can see a value for values written in datastore to also be persisted into the .cfg file to be available after reboot. In a previous product from my past life - there used to be an explicit "save" command (for the config to be persisted). Not sure if that is what should be followed here (an explicit REST API for "save" - or should we implicitly "save" the config to the ".cfg" file? On Thu, 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]> > 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
