[
https://issues.apache.org/jira/browse/HBASE-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248459#comment-13248459
]
Subbu M Iyer commented on HBASE-3909:
-------------------------------------
@Uma:
5. getMaster().updateConfig is not deprecated. It is used by the Shell.
7. If ZK is down or connectivity is lost we have much bigger problem then
loosing a config update.
8. Yes. I thought of creating two buckets of configuration elements. 1)
Bootstrap config items which may not be changed after the cluster is up or have
no effect changing them once cluster is up 2) Non bootstrap, truly runtime
configurations which have immediate effect. My thought was to add these
features if there is a consensus from the group.
9. Yes. But if a user is changing the configuration either in XML or dynamic he
is better aware of the implications. no?
10. NodeDeleted is not required. We are not going to delete a configuration
entry at runtime and even doing so may not have any effect now. In the future
if we want to trigger some actions based on presence/absence of some
configuration entries this might be added.
11. Yes, we can offer a Master/RS specific fine grained configuration controls
if that is a real requirement. My thought is begin with some thing
very simple and add complexities as we see fit. So, one option is as we all
know is to create separate subset of config nodes per Master/RS in the cluster
and they subscribe to events specific to their own subset. But, if you look at
our current configuration xml we make no clear distinction as to which
properties belong to which runtime entity. Although we name them like
config.key.master or config.key.region, I am not sure whether we can count on
them to make a decision on whether a property applies to MAster only or RS only
and so on.
12. My thought is InMemory Configuration holds the config items after creating
a ZK node for the same as other wise it may not be altered. Basically we need
to make sure that ZK config node exists for a config key before we keep it in
memory.
13. My thought is ideally we want Master to be the single point of source for
all cluster wide config management/updates. We definitely don't want to
directly manipulate a RS specific property. I mean we should not expose API's
in RS to enable config key manipulations. Master should be the single point of
source for all configuration entries irrespective of whether the config is
cluster wide, master specific or RS specific and ZK should be the medium of
communication across the cluster. So, master will be involved in all config
updates is my take.
Others please comment.
> Add dynamic config
> ------------------
>
> Key: HBASE-3909
> URL: https://issues.apache.org/jira/browse/HBASE-3909
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Fix For: 0.96.0
>
> Attachments: 3909-v1.patch, 3909.v1
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
