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 >
