Mailing-List: contact user-help@helix.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@helix.incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of kanak.b@hotmail.com
 designates 65.54.190.211 as permitted sender)
Message-ID: <BAY173-W2832F9918996AF3F109BC6ED280@phx.gbl>
From: Kanak Biscuitwala <kanak.b@hotmail.com>
To: "user@helix.incubator.apache.org" <user@helix.incubator.apache.org>, dev
	<dev@helix.incubator.apache.org>
Subject: RE: New rebalancers: deltarebalancer & rebalancer
Date: Thu, 26 Sep 2013 16:54:08 -0700
Importance: Normal
In-Reply-To: <BAY173-W25555314E7EBF9B784F95FED280@phx.gbl>
References: 
 <CABaj-QbCmUgBHGCotQwyGByGtkHFw5DZDJ7DTaUXj2y9o8FDkQ@mail.gmail.com>,<BAY173-W25555314E7EBF9B784F95FED280@phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Well actually I guess I can answer my own question: the current rebalancer =
interface seems to be general enough to support adding a new delta implemen=
tation that would fit in the current pipeline.=0A=
=0A=
----------------------------------------=0A=
> From: kanak.b@hotmail.com=0A=
> To: user@helix.incubator.apache.org=3B dev@helix.incubator.apache.org=0A=
> Subject: RE: New rebalancers: deltarebalancer & rebalancer=0A=
> Date: Thu=2C 26 Sep 2013 16:51:42 -0700=0A=
>=0A=
> Seems reasonable. I guess this doesn't fit into a traditional state model=
 because the rebalancer can generate a new "state" each time. Do you envisi=
on this being a generalization of the current rebalancer=2C or as part of a=
 new pipeline?=0A=
>=0A=
> Kanak=0A=
> ________________________________=0A=
>> Date: Thu=2C 26 Sep 2013 10:53:44 -0700=0A=
>> Subject: New rebalancers: deltarebalancer & rebalancer=0A=
>> From: g.kishore@gmail.com=0A=
>> To: dev@helix.incubator.apache.org=3B user@helix.incubator.apache.org=0A=
>>=0A=
>> Hi=2C=0A=
>>=0A=
>> I am thinking of adding a delta rebalancer that simple compares the=0A=
>> delta between idealstate and currentstate and generate transitions for=
=0A=
>> the delta. The main difference from existing implementation is that=0A=
>> this does not need a state machine or any constraints on the state.=0A=
>>=0A=
>> Where can this be useful=0A=
>> One scenario where this can be useful is managing the config versions.=
=0A=
>> For example we can say=0A=
>>=0A=
>> Node1:1.3=0A=
>> Node2:1.3=0A=
>>=0A=
>> Each version can correspond to a set a config properties. If a new=0A=
>> config is uploaded with new version=2C we send the transition for each=
=0A=
>> node to refresh the config. The benefit of this is clients will know=0A=
>> what is the config version the participant is running. And leader can=0A=
>> ensure that all participants are upgraded to latest config.=0A=
>>=0A=
>> We can take this a step further and allow the idealstate to be more=0A=
>> expressive=0A=
>>=0A=
>> for example the state can be composed of multiple attributes=0A=
>>=0A=
>> N1: {a: aval=2C b:bval=2C c:cval}=0A=
>> N1: {a: aval=2C b:bval=2C c:cval}=0A=
>>=0A=
>>=0A=
>> And we can change each value independently.=0A=
>>=0A=
>> N1:{a:avalnew=2C b:bval=2C c:cval}=0A=
>>=0A=
>> we could then invoke the appropriate call back on the participant that=
=0A=
>> a changed and once the callback is processed the current state changes.=
=0A=
>>=0A=
>> This kind of becomes a general way to manage configuration and keep=0A=
>> track of what config the node is using. Note this is not supposed to=0A=
>> say every single config property but it could be used to represent high=
=0A=
>> level config properties.=0A=
>>=0A=
>>=0A=
>> Thoughts/feedback? At LinkedIn=2C i think this will help us manage schem=
a=0A=
>> versions.=0A=
>>=0A=
>> Thanks=2C=0A=
>> Kishore G=0A=
>>=0A=
>>=0A=
>>=0A=
>>=0A=
>>=0A=
>>=0A=
>>=0A=
>>=0A=
>> 		 	   		  =