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 >
