-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
replicated state machine improvements #3
Comments
another important thing to do here is to change the replicated behavior to get role information. i.e. whether or not it is the primary or a follower. we also need to decide whether or not a follower gets its number, or just the information that it is a follower. We want to do this to guarantee e.g. that only one member can do a particular thing with a global side effect (check on another machine, write to a durable data store). |
thirdly, it'd be nice to change the replicated state machine to something closer to gen_statem. The actions are nice, the singler event handler function is easier to support, and I'd like to be able to support internal actions so that we can pass internal operations back through the replicated machinery in and idiomatic way. |
another thing that's required is to improve the consistency of state machine handling. there are at least 4 places where upcalls to the replicated state machine can happen, and they're poorly standardized. We need to update the client table on followers, and make sure that we gracefully handle a replicated state machine that returns |
similar to vmware-archive/haret#103, the replicated state machine should be able to tell the vrrm machinery not to add something to the log when it does not mutate the inner state.
keep_state
and optimize log to use that informationThe text was updated successfully, but these errors were encountered: