My opinion, use conf file as default, and use code to override the config in conf file. And we need to persist the overridden value somewhere, not zk I'd say. I agree with Matteo that we should reduce the dependency of zk. Maybe we could introduce an hbase:config table?
And for the dynamic configuration framework, it is difficult to treat all configurations in the same way I think. I prefer changing all configurations with a shell command(the actual implementation should an RPC call to master maybe), but if we have regionservers with different hardwares in cluster, they may have different configurations so modify conf file directly on the machine is a more proper way? I have no idea... Thanks. 2016-02-04 11:40 GMT+08:00 Enis Söztutar <e...@hortonworks.com>: > This came up in the review for HBASE-15128, but we thought that we should > surface this discussion in dev@. > > The idea for HBASE-15128 is that, we should have a dynamic switch in master > so that the operator (or HBCK) can disable all region splits or merges. > > We currently have such dynamic switches for balancer and normalizer which > keep their state in zk. We also have a switch for catalog janitor which > keeps its state only in memory (not sure why). For the new switches Heng > Chen implemented a "set_switch" RPC to master, a switch type, a zk node. > The idea is to move balancer, catalog janitor and normalizer switches to > this after this patch. > > However, Matteo raised a point about this framework being an alternative > way of doing dynamic configuration. The problem is that we do not have a > dynamic conf framework that we can piggyback on, and since balancer and > other switches already work this way, it does not make sense to block the > issue. What do you guys think? If we want to implement dynamic conf, how > would we handle things like enabling / disabling balancer from conf and or > from code? Any good ideas? > > Enis >
