Build out cluster of N nodes. Mis-configure one node so that -name in vm.args remains as email@example.com. Add all nodes to cluster and commit cluster plan.
Stop firstname.lastname@example.org node.
Use riak-admin force-remove -f email@example.com on another node.
riak-admin force-remove -f firstname.lastname@example.org
Re-configure the email@example.com node to have the correct -name in vm.args and remove ring/ data. Re-start node, re-join it to the cluster, and re-commit the cluster plan.
Use riak attach to attach to another node in the cluster and rp() the ring. You will see that firstname.lastname@example.org remains in the ring indefinitely.
One Riak EE user reports that the presence of email@example.com causes errors after setting up fullsync repl and executing the fullsync. Please see ZD ticket 6100 for details.
@lukebakken just wondering if you had made any more progress on that ticket that might shed light on this issue. iirc we discussed that the 'firstname.lastname@example.org' values remained in the vector clock (and the vector clocks in the seen set) but could not be found elsewhere and this was determined not to be a problem.
Does the scenario you describe leave membership in an incorrect state or was it just the leftover traces of the old node name that was the concern? If its the latter can this issue be closed?
@jrwest - I don't think that this is related to 6100 anymore. However, I'm going to wait until that ticket is closed to be sure.
Otherwise, this just appears to be a super-low-priority big.
I'm going to go ahead and close this issue. from what I can tell the problem either lived in repl's handling of the ring or not at all. The actor ids from old nodes will certainly live on the vector clocks and should not be a problem. happy to re-open if we run into it again.