[
https://issues.apache.org/jira/browse/HBASE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitay Joffe updated HBASE-1606:
-------------------------------
Attachment: hbase-1606-v2.patch
Same patch, rebased to latest trunk.
> Remove zoo.cfg, put config options into hbase-site.xml
> ------------------------------------------------------
>
> Key: HBASE-1606
> URL: https://issues.apache.org/jira/browse/HBASE-1606
> Project: Hadoop HBase
> Issue Type: Sub-task
> Affects Versions: 0.20.0
> Reporter: Nitay Joffe
> Assignee: Nitay Joffe
> Fix For: 0.20.0
>
> Attachments: hbase-1606-v2.patch, hbase-1606.patch
>
>
> From HBASE-1551:
> Here's my current thinking:
> * Move all of the ZooKeeper config paraments into hbase-*.xml using
> zookeeper.property.KEY = VALUE.
> * Add a special property for the list of quorum servers, say
> zookeeper.quorum. This option can default to "localhost".
> * If there is a zoo.cfg present in the classpath, use its data above the
> zookeeper.property.KEY options.
> * When we need to instantiate something to talk to ZooKeeper, we simply
> create a new HBaseConfiguration and call some method on it e.g.
> toZooKeeperProperties().
> This method will iterate through the zookeeper.property.KEY and turn
> each into the appropriate ZooKeeper configurations (i.e. KEY=VALUE). It will
> generate
> the server.X property from the zookeeper.quorum configuration option.
> As mentioned above, if there is a zoo.cfg in the classpath, overwrite the
> data with its configuration.
> This will return a Properties object that can be used to construct the
> appropriate ZooKeeper config and start/talk to their servers.
> * For start/stop management of full ZK quorum cluster, use something like
> my ZKServerTool in the patch (modified of course) to do the parsing mentioned
> above and turn it
> into a simple line-by-line list of quorum servers. As I do in this
> patch, the bin/zookeepers.sh can then simply call bin/hbase
> o.a.h.h.z.ZKServerTool to get the list of hosts.
> If you want something like a conf/zookeepers you can simply run
> ZKServerTool yourself.
> The benefits from all this are:
> * One place for all ZK configuration. No duplicate setting of parameters.
> * No more nasty zoo.cfg. Give the user what they're already used to, a
> single XML config file.
> * New user only need edit zookeeper.quorum to get full cluster.
> * Programmable control of what ZK one is talking to.
> And some of Stack's comments:
> @nitay, I think you need to keep the hbase zookeeper config inside of an
> hbase namespace. The Hadoop Configuation system is a floozy. It will go with
> anyone who calls load resource on it pulling in their properties. I could see
> that out on a MR task, the Configuration could have all kinds of pollution in
> it. Would suggest an hbase prefix - hbase.zookeeper prefix?
> @nitay on "if zoo.cfg in the CLASSPATH", that might work. We might want to
> try narrow the places we look on the CLASSPATH. But lets start open and
> narrow later (we probably want this to be open as possible at mo. until we
> learn more about the cloudera config.)
> @nitay on toZooKeeperProperties, do we have to expose that? Can't we just
> pass a HBaseConfiguation to the HBase ZK Wrapper (I'm not up on latest dev
> here so this might be an off suggestion)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
