Skip to content

Bugfix/pending peer dataloss#20

Closed
andrewjstone wants to merge 3 commits intodevelopfrom
bugfix/pending-peer-dataloss
Closed

Bugfix/pending peer dataloss#20
andrewjstone wants to merge 3 commits intodevelopfrom
bugfix/pending-peer-dataloss

Conversation

@andrewjstone
Copy link
Copy Markdown
Contributor

Remove the pending state in riak_ensemble_peer so that we are no longer vulnerable to dataloss with pending peers. See individual commit messages for more info.

Solves #17

This test will fail when we automatically trust pending peers.
This allows us to reach a new quorum of peers that don't contain data,
because we aren't syncing when pending peers startup. This can result in
existing data being returned as `notfound`. Fixing this failing test
requires syncing data before transitioning to the final view.

Test for #17
The pending state allows pending peers to act trusted, when they
shouldn't be. It is also unnecessary. Removal of the pending state makes
pending_dataloss_test.erl pass and completes #17.

Pending views are only needed to ensure propogation of views so that
peers may be started dynamically on remote nodes before the leader
transitions to using them. If the leader tried to use the peers before
they were up, he would lose leadership and the peers may never be
started because they require propogation to the manager from the leader
to start them.  Therefore pending views were introduced to help ensure
those peers were started and stable leadership was maintained. However,
once those peers are started they are just normal peers and don't need
to do anything special outside the protocol. Therefore there is no need
for a separate pending state.

A better description by @jtuple is in this comment:
01dda5a#commitcomment-5888125
Do not search for rebar in path in Makefile
@jonmeredith jonmeredith added this to the 2.0-RC milestone May 12, 2014
@jtuple jtuple self-assigned this May 13, 2014
@jtuple
Copy link
Copy Markdown
Contributor

jtuple commented Jun 23, 2014

I still need to decide if this is the right approach or not, I'm not 100% certain about deleting pending state. I'll try and make this decision today. We'll either merge this, or I'll throw together a PR for the alternate approach that I originally suggested in #17.

More importantly, the notion of what "trust" is will be changing if the new syncing/integrity checking PR lands. Possibly making this entire change unnecessary in the first place.

@andrewjstone
Copy link
Copy Markdown
Contributor Author

Closing. Not needed as a result of #37

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants