It seems questionable to me that you would have one locator with CC enabled and another with CC disabled. Usually you have extra locators for fault tolerance. What happens if the one with CC enabled dies? Will gfsh commands quit getting recorded in CC because we now only have a locator with CC disabled? I agree with Jake that the locators should have matching CC configuration. Does a use case exist that requires a locator that does not have CC enabled on a cluster that does?
If we want to have gfsh commands that are intentionally transient (i.e. not remembered in CC) then I think that should be an option on the gfsh command itself. But you also need to consider who the gfsh commands will work on a cluster that has not enabled CC. On Tue, Jan 3, 2017 at 8:51 AM, Jinmei Liao <jil...@pivotal.io> wrote: > 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 >
