[
https://issues.apache.org/jira/browse/HBASE-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037419#comment-13037419
]
stack commented on HBASE-3909:
------------------------------
Some push back:
bq. we already require at least one piece of configuration in the client itself
in order to connect to ZooKeeper (ie the ZK quorum info and session timeouts,
etc)
True, but we do keep config in two places -- in hbase-*.xml and in
conf/hbase-env.sh. If only an ensemble location (and optional timeout) could
be environment variables.
bq. operations teams are very good at managing text-based configuration files
with tools like puppet, cfengine, etc. It's also easy to version-control these
kinds of configs, add <!-- comments -->, etc. Moving to ZK makes these tasks
more difficult – we'd need lots of tooling, etc.
If we move our config. totally to zk, true (This is a good point though. We
are providing a software package that is going to be deployed in all kinds of
environments. We need to do the LCD).
bq. If we keep both the text-based and ZK-based, it's easy to accidentally
change something in ZK but forget to update in text, so it would revert on next
restart.
What I was thinking was that the text-based would seed zk. Changes would be
made to the text-based config. and would then have to be hoisted up into zk for
the changes to have an effect. Part of master startup would be putting the
config. up in zk for clients and regionservers to use (Currently, regionservers
get critical config. from the master, not from reading text-based file in their
conf dir as part of the checkin).
bq. we currently have the somewhat nice property that nothing in ZK is
"critical" - even if the ZK cluster is completely wiped out, we dont lose any
info. This would be a change.
This needs to become a golden rule going forward. Where do we etch it? (If
we do the above where master posts config. to zk, then zk is not the sole
repository for config.)
I suppose I think there is still merit in the original proposal for using the
zk watcher 'message bus' propagating config. changes but need to study
hadoop-7001 more I say anything more.
> Add dynamic config
> ------------------
>
> Key: HBASE-3909
> URL: https://issues.apache.org/jira/browse/HBASE-3909
> Project: HBase
> Issue Type: Bug
> Reporter: stack
>
> I'm sure this issue exists already, at least as part of the discussion around
> making online schema edits possible, but no hard this having its own issue.
> Ted started a conversation on this topic up on dev and Todd suggested we
> lookd at how Hadoop did it over in HADOOP-7001
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
