yeah, the reason we have issue2 is because of issue1, if we fix issue1, then local changes are definitely more welcome than remote calls. The whole idea of proposing change#2 is to get rid of some of the silliness of the implementation. Change #2 would get rid of 4or 5 remote functions class at least. The only change is that when user is connected to a locator without CC, the command will get a output message saying "CC is not affected", but we all know it's a rare case anyway.
On Tue, Jan 3, 2017 at 10:41 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > 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 > > > -- Cheers Jinmei
