Currently our API or gfsh commands allow you to create a cluster with a mix of locators with and without CC. Our DM maintains a list of locators and a separate list of locators with CC enabled. It is bad, I know. But I am not sure if we can change it.
Assuming we have to live with cluster with mix of locators, would my proposal make sense? On Tue, Jan 3, 2017 at 9:59 AM, Udo Kohlmeyer <u...@apache.org> wrote: > +1 > > I think that the configurations of all locators should be identical, or at > least in terms of a few "critical" properties. One would also need to be > able to amend some property changes at runtime, to allow for the changing > of configuration without taking all the locators offline. "remote-locators" > would be a good candidate. > > --Udo > > > > On 1/3/17 09:50, Jacob Barrett 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 >>> >>> > -- Cheers Jinmei
