+1 for what Jake said - I think locators should refuse to join if their settings don't match.
Having a mix of locators that do and don't support cluster configuration seems confusing. That means your system may or may not update cluster configuration, depending on which locators are actually running at any given time. -Dan On Tue, Jan 3, 2017 at 9:50 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > If we consider the locators as the directory service for the cluster then > it makes no sense for them to be configured differently. I think locators > should be force to adopt the configuration of the other locator in the > cluster or refuse to join the cluster until their config is updated to > match. > > > > On Tue, Jan 3, 2017 at 8:52 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 > > >
