+1 to reducing dependency on zookeeper
> On Feb 3, 2016, at 9:50 PM, 张铎 <palomino...@gmail.com> wrote: > > 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 >>
