Currently there is no way for a machine to know what the current cluster membership is.
Add an option to call ra_machine:apply/4 with a new command type, similarly to how the noop command translates into a {machine_version, _, _} command that is dispatched against the machine. So when we apply a $cluster_change command we translate this into a {membership_change, OldMembers, NewMembers} command.
There has to be an opt-in mechanism to avoid this becoming a breaking change as current machine implementations may not handle unknown commands.
where the feature name for this would be member_change_command
It may be necessary to inject a command at some point when a cluster is started with an initial member set else there would be no way to know the initial members unless they changed as there is no $cluster_change command for initial members.
With the new handle_aux/5 API it is possible to detect member changes by checking the ra_aux:member_info/1 for each handle_aux(eval, event and comparing that to a stashed copy. Closing.
Currently there is no way for a machine to know what the current cluster membership is.
Add an option to call
ra_machine:apply/4
with a new command type, similarly to how thenoop
command translates into a{machine_version, _, _}
command that is dispatched against the machine. So when we apply a$cluster_change
command we translate this into a{membership_change, OldMembers, NewMembers}
command.There has to be an opt-in mechanism to avoid this becoming a breaking change as current machine implementations may not handle unknown commands.
ra_machine:supports_feature(FeatureName :: atom())
where the feature name for this would be
member_change_command
It may be necessary to inject a command at some point when a cluster is started with an initial member set else there would be no way to know the initial members unless they changed as there is no
$cluster_change
command for initial members.