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.