Hi Vinayak, Good point. I think invoking rebalance is required for Helix to start sending any transitions for that resource. But we need to provide better api to explictly control. We need to have the concept of explicitly activating/deactivating a resource. It goes well with the concept of disabling node/partition.
Do you want to file a jira and fix this. This is quite simple and easy to change. Once we have this, we can provide a high level api that takes idealstate, config etc and simply creates resource in disabled state/sets up everything/ and finally activates it. Eventually we can use zk multi transaction to guarantee atomic update. What do you think? thanks, Kishore G On Wed, May 8, 2013 at 9:04 AM, Vinayak Borkar <[email protected]> wrote: > Hi, > > > I have a fundamental question about guarantees in Helix regarding newly > added resources and their configuration. > > When I add a new resource into Helix, I need to first configure it by > setting some properties using the ConfigAccessor. AFAICT Helix does not > provide a way to do both the steps (add the resource and configure it) in > one atomic step. Another thing I noticed is that addition of a new Resource > into Helix even in AUTO_REBALANCE mode does not immediately trigger a > External State computation. Instead I seem to need to call rebalance on > that resource. Since I need the configuration set before state models at > the nodes start manipulating the resource, this is perfect. It allows me to > add a resource, configure it and then call rebalance so the state models do > not see an unconfigured resource. > > My question is if this is a guarantee provided by Helix? i.e. Is > rebalancing of a new resource triggered ONLY by an explicit rebalance call? > > I have read/heard of a rebalance timer. How do I set that value and does > that impact rebalancing of new resources? > > Thanks, > Vinayak >
