Ok, currently we have 2 issues: 1) a cluster might have a mix of locators with and without CC enabled. The change proposed is to reject locator that does not CC enabled to join a locator that has CC enabled (or vise versa). 2) commands that change CC does remote calls to a locator with CC to change the cluster config. The change proposed is to simply do it on the current locator.
Fix for issue 2 is NOT a workaround for issue 1, it's a step towards fixing issue 1. No matter we fix issue 1 or not, change for issue 2 is needed. On Tue, Jan 3, 2017 at 10:18 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > I am not a fan of complicated work arounds for things like this. Feels like > a lot of moving parts to address something that was more likely a careless > oversight than an intended use case. Why do you feel like we can't address > the underlying issue? > > > On Tue, Jan 3, 2017 at 10:05 AM Jinmei Liao <jil...@pivotal.io> wrote: > > > 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 > > > -- Cheers Jinmei
