Ensure ClaimLRP request for suspect LRP is ignored #514
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Submodule src/code.cloudfoundry.org/bbs fa06428..9c1884f: > Ensure claim LRP request for suspect LRP is ignored Resolves cloudfoundry/bbs#42 Co-authored-by: Sunjay Bhatia <[email protected]>
|
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story. The labels on this github issue will be updated when the story is started. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a cell loses presence and tries to claim an LRP that it owns, we want to ignore the request and let convergence etc. properly take action to right the ship. If we let the suspect cell claim a suspect LRP, it causes any replacement UNCLAIMED ORDINARY LRP (which has the same key) to be updated and transition to CLAIMED ORDINARY (and be claimed by the suspect cell).
This causes there to be 2 LRPs with the same key and instance key, but different presences. When a subsequent Start request comes in from the suspect cell for the suspect LRP, it is not ignored as intended, but instead the replacement LRP that was erroneously moved to CLAIMED is transitioned to RUNNING.
This then causes the CLAIMED SUSPECT LRP to be removed, generating an unexpected actual_lrp_removed event.
Address: cloudfoundry/bbs#42