Cluster Config

[Jinmei Liao <ji...@pivotal.io>]

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

Re: Cluster Config

[Darrel Schneider <ds...@pivotal.io>]

It seems questionable to me that you would have one locator with CC enabled
and another with CC disabled. Usually you have extra locators for fault
tolerance.
What happens if the one with CC enabled dies? Will gfsh commands quit
getting recorded in CC because we now only have a locator with CC disabled?
I agree with Jake that the locators should have matching CC configuration.
Does a use case exist that requires a locator that does not have CC enabled
on a cluster that does?

If we want to have gfsh commands that are intentionally transient (i.e. not
remembered in CC) then I think that should be an option on the gfsh command
itself. But you also need to consider who the gfsh commands will work on a
cluster that has not enabled CC.

On Tue, Jan 3, 2017 at 8:51 AM, Jinmei Liao <ji...@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
>

Re: Cluster Config

[William Markito Oliveira <ma...@apache.org>]

+1 -  Configuration should be consistent on the locators, specially cause
we should consider them source of truth for "distributed configuration"
anyway...

On Tue, Jan 3, 2017 at 1:59 PM, Swapnil Bawaskar <sb...@pivotal.io>
wrote:

> I think we should not allow a mix of cc enabled or disabled across any
> member in the cluster (servers as well as locators)
> https://issues.apache.org/jira/browse/GEODE-1961.
>
> On Tue, Jan 3, 2017 at 11:25 AM, Jinmei Liao <ji...@pivotal.io> wrote:
>
> > 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 <jb...@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 <ji...@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 <jb...@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 <ji...@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 <ud...@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 <jiliao@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
> >
>

Re: Cluster Config

[Swapnil Bawaskar <sb...@pivotal.io>]

I think we should not allow a mix of cc enabled or disabled across any
member in the cluster (servers as well as locators)
https://issues.apache.org/jira/browse/GEODE-1961.

On Tue, Jan 3, 2017 at 11:25 AM, Jinmei Liao <ji...@pivotal.io> wrote:

> 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 <jb...@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 <ji...@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 <jb...@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 <ji...@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 <ud...@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 <ji...@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
>

Re: Cluster Config

[Jinmei Liao <ji...@pivotal.io>]

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 <jb...@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 <ji...@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 <jb...@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 <ji...@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 <ud...@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 <ji...@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

Re: Cluster Config

[Jacob Barrett <jb...@pivotal.io>]

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 <ji...@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 <jb...@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 <ji...@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 <ud...@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 <ji...@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
>

Re: Cluster Config

[Jinmei Liao <ji...@pivotal.io>]

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 <jb...@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 <ji...@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 <ud...@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 <ji...@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

Re: Cluster Config

[Jacob Barrett <jb...@pivotal.io>]

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 <ji...@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 <ud...@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 <ji...@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
>

Re: Cluster Config

[Jinmei Liao <ji...@pivotal.io>]

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 <ud...@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 <ji...@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

Re: Cluster Config

[Udo Kohlmeyer <ud...@apache.org>]

+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 <ji...@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
>>

Re: Cluster Config

[Dan Smith <ds...@pivotal.io>]

+1 for what Jake said - I think locators should refuse to join if their
settings don't match.

Having a mix of locators that do and don't support cluster configuration
seems confusing. That means your system may or may not update cluster
configuration, depending on which locators are actually running at any
given time.

-Dan

On Tue, Jan 3, 2017 at 9:50 AM, Jacob Barrett <jb...@pivotal.io> 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 <ji...@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
> >
>

Re: Cluster Config

[Jacob Barrett <jb...@pivotal.io>]

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 <ji...@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
>