Calling all the pros with knowledge on cluster configurations: This is regarding this current behavior of Cluster Config: Assuming a cluster has 2 locators, locator-A-with-CC (with cluster config enabled), and locator-B-without-CC (without cluster config enabled), currently any commands a user executes through Gfsh that affects cluster config (create region, deploy/undeploy etc) will change cluster config no matter which locator he connects to.
The implementation of this behavior is quite complicated: the command needs to: 1. find out from DM if there is any locator that has CC enabled (the DM needs to maintain a flag simply for this purpose). 2. find out from DM the list of locators that has CC enabled. 3. loop through this list, execute a remote function on that locator to change the CC. (depending on the nature of the command, the function is different). 4. break out of the loop if one execution is successful. (it only needs to update only one locator, since the cc region is replicated across locators). Quite often, the locator that ends up executing the function call will the be locator that executes the command, but we still need to do the remote call. So I am wondering: A: What are the use cases where a cluster might have a mix of locators with and without CC? Is it quite common? B: Is there a chance that when a user connects to a locator without CC enabled, he actually WANTS all the commands he execute WON'T affect CC? C: Can we change the behavior to B? That is: the commands will only change CC only if the user is connected to a locator that has CC enabled? (of course, we will provide enough warning if the commands are on a locator without CC telling him that won't affect cluster config. We will also provides commands that will show the current state of Cluster Config) This behavior change would greatly simply our implementation of cluster config and get rid of lots of spaghetti code. -- Cheers Jinmei
