[GitHub] [hbase] virajjasani commented on pull request #2523: HBASE-25167 Normalizer support for hot config reloading
virajjasani commented on pull request #2523: URL: https://github.com/apache/hbase/pull/2523#issuecomment-708256369 > The `_switch` commands are simple booleans only. That's true, `_switch` commands store just boolean, so not a big concern. However, I like it in a way that operator doesn't have to update on disk configs for live cluster. But on the other hand, we have a new znode dependency. As for the rate limiter, since we are expecting changes in configs related to how many bytes of sized regions we want to get normalized with rate limit, I think we should be good with current approach. Thanks, taking a look. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] virajjasani commented on pull request #2523: HBASE-25167 Normalizer support for hot config reloading
virajjasani commented on pull request #2523: URL: https://github.com/apache/hbase/pull/2523#issuecomment-707605198 We used to have 2 types of hot config reload: 1. `_switch` commands (e.g `balancer_switch`) which uses znode to update config on/off values and hence, even after master failover, new active master would be able to read config value from znode and stay up-to-date even in the presence of stale config value on hbase-site. 2. `ConfigurationObserver` with implementation of `onConfigurationChange()`, which requires operator to update new config value on all desired servers e.g all masters (active + backup) and then utilize config reload commands `update_config` or `update_config_all`. Since I haven't used (looking forward to dig deeper) `PropagatingConfigurationObserver`, one question is, does it also require updating configs on disk to make sure if master fails-over, next active master reloads config from disk or we have some rendezvous like ZK being used under the hood that ensures config change on disk is not mandatory? I am also not a fan of using another new znode, just trying to understand the crux of hot reload of config and it's impact related to stale config value presence on backup master. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
