If you fix issue 1 do you really need to change 2? I agree it is silly that it remotes to another locator to execute the CC change but would it have any effect should all the locators be configured the same?
On Tue, Jan 3, 2017 at 10:29 AM Jinmei Liao <jil...@pivotal.io> wrote: > 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 >
