-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
Add hashKV checking to robustness test #18386
Comments
Three cases I can think of,
But we need to exclude false alarm. The compaction is executed in the applying workflow/path, but hashKV is executed in the API layer. The etcd/api/etcdserverpb/rpc.pb.go Lines 1634 to 1638 in 739a9b6
|
/assign @ArkaSaha30 We would like to work on this together as this also seems to be a good material for the talk that we might be preparing for! |
@henrybear327: GitHub didn't allow me to assign the following users: ArkaSaha30. Note that only etcd-io members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/assign |
Sound good to me! Especially, it can help us to do sanity and compatible check on mix-versions cluster. |
I don't know if anyone needs an extra pair of hands i'm here just ping me @ArkaSaha30 @henrybear327 |
ping @henrybear327 @ArkaSaha30 any progress? |
What would you like to be added?
#18274 proposes to change very delicate part of compaction to fix a correctness bug. There is high concern in this change potentially changing result of hashKV which can lead to cluster incorrectly marking itself as corrupted. We need to build a very solid confidence in hashKV calculation which regards to traffic and compaction.
Robustness tests seem like a good candidate to build that confidence even further, the main challenge in adding tests like in #18369 is fact that we cannot easily cover all ways requests (PUT/DELETE/TXN/Compaction) can interleave. With Robustness generating random requests it seems that we just need to start checking hashKV.
Robustness tests could be periodically requesting hashKV from all members and validating them for equality.
Why is this needed?
Would like to generalize testing for #18369.
The text was updated successfully, but these errors were encountered: