This is very useful Kanak. I think a Helix beginner will probably need something like this. How about a quick sync up on IRC (#apachehelix) at 2:00 PM PST.
thanks, Kishore G On Mon, Mar 10, 2014 at 12:40 PM, Kanak Biscuitwala <[email protected]>wrote: > > Hi, > > I added a new section to the wiki page. It's called definitions and it > enumerates the Helix entities, what they do, and what scope they work at. I > hope this will be a good starting point as it more or less describes all > the functionality that this API needs to support/simplify. > > https://cwiki.apache.org/confluence/display/HELIX/API+Redesign+-+Progress > > Thanks, > Kanak > > ---------------------------------------- > > From: [email protected] > > To: [email protected] > > Subject: RE: Questions on Helix Model > > Date: Sun, 9 Mar 2014 18:04:02 -0700 > > > > > > Responses inline. Can you please define "model" and what should and > shouldn't be a model? I'm a little unclear here. Also, it seems like > there's already classes doing what you're suggesting in some cases. I'm not > sure how we can best communicate when that is the case in general. > > > > ---------------------------------------- > >> Date: Sun, 9 Mar 2014 17:16:58 -0700 > >> Subject: Questions on Helix Model > >> From: [email protected] > >> To: [email protected] > >> > >> Hey guys, > >> > >> I got a chance to get back to the model and had a few questions. All > >> these are aligned towards cleaning up the model. Let me know if I am > >> going down the wrong path in wanting to clean up the model. > >> > >> * Are constraints only applied to cluster? > > > > No, they can be applied at cluster, resource, participant, and partition > scopes. Currently the Helix admin takes a scope paramater in when setting > constraints. We can either continue to do this, or expose constraint > commands for each scope builders. > > > >> > >> * What entities is CurrentState applicable to? It appears it applies > >> to a resource + partition combination, am I correct? If so why not add > >> the concept of 'Partition' to the model and have it return resources > >> and have state on the resources? > > > > Current state only exists at the scope of a participant. It's a runtime > entity which indicates which resource partitions a node has and what state > they are in. I wouldn't agree with partitions returning resources because a > partition is a subset of a resource and a node can serve multiple > partitions of the same resource, as well as multiple resources. > > > >> > >> * Is there a reason we don't have a base 'State' to have derived > >> states of IdealState(end state) and CurrentState(where we are in the > >> transition)? That way we could potentially add StartState(start of > >> transitions) and IntermediateState(any one of the states transitioned > >> to while getting to ideal state) as a place holder for all other > >> states. What do you think? > > > > Because 'State' means something else in Helix terminology. It's the > state of a single replica of a partition (i.e. it's scoped the same as a > StateModelDefinition). > > > > I think IdealState and CurrentState are self-explanatory. I don't think > adding more classes and interfaces with respect to these two will improve > understanding, and will only cause confusion if people stumble across old > documents. > > > >> > >> * Is there a reason you guys decided not to have a representation of > >> 'Cluster' in the model? > > > > The only entities that are cluster-wide are auto join status, > constraints, and user configurations. We have something called > ClusterConfiguration in the old model that sort of captures this. We also > have a ClusterConfig and a Cluster (for runtime snapshots) class. > > > >> > >> * HelixConfigScope applies to configurations related to Cluster, > >> Resource, Participant, Partition and Constraint. Constraint appears to > >> be the odd man, can we fix this? How about having Configuration > >> hierarchy i.e. ClusterConfiguration, ResourceConfiguration, > >> PartitionConfiguration and so on and do away with Scope? > > > > I would stop using HelixConfigScope and start using Scope where > possible. We do have this hierarchy in ClusterConfig, ResourceConfig, and > ParticipantConfig. > > > >> > >> * We should remove the AlertsHistory, LeaderHistory from the model > >> package. These are not true model elements, what do you guys think? > >> > > > > AlertsHistory should go away from Helix altogether. No one uses it and > it's not scalable. Leader history is a useful runtime thing to expose in > the cluster snapshot class (Cluster). > > > >> * We should remove StateModelDefinition, Transition and State from > >> model, it is not core model. It applies to entities in the model. What > >> do you guys think? > >> > > > > They're core Helix concepts. I don't know if that means they should be > models or not. > > > >> * We should remove Message from model, its not a model entity. It > >> needs to be a separate package, let me know what you guys think? > >> > > > > We support sending messages between nodes in the cluster. Whether or not > they should be in model depends on how you define model. > > > >> * LiveInstance should go away, we should only have a status on the > >> Participant. Let me know what you guys think? > >> > > > > This is runtime information, and see the Participant class, which is > meant to be a runtime snapshot of a participant. We can't just have a flag > of live/not live. It's also important to know pid, qualified host, and > version. > > > >> I am hoping to work a bit on the model tonight, so let me know what > >> you guys think. > >> > >> Thanks, > >> > >> Sandeep > > > >
