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
