-
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
*: keep tombstone if revision == compactAtRev #18274
Conversation
Skipping CI for Draft Pull Request. |
bb203a1
to
a89b240
Compare
ping @ahrtr @serathius @siyuanfoundation @chaochn47 ~ PTAL, thanks |
I think it's expected behavior. Compaction always keeps the latest revision K, which is <= compaction_rev. |
The e2e test cases, especially the mix-version test cases, as mentioned in #18162 (comment) are important. What's the plan to implement the e2e test cases? |
ETCD server prevents requests from fetching revisions which are smaller than compacted revision. It looks fine to me.
For the mix-version part, it's hard to finish it in one request. I'm trying to use patch mode in this pull request, like https://github.com/etcd-io/etcd/blob/main/tests/robustness/patches/beforeSendWatchResponse/watch.patch. |
It sounds reasonable, but we still have two options, either keep it as it's or fix it. The rev, which is smaller than compaction rev, isn't accessible via the get/range API, but it's still in the db file. I agree it's an issue, but it seems harmless. Fixing it may break user experience as well. If we decide to fix it (let's go for this direction if there is NO objection),
It's OK to do it in followup PR, but we should manually verify it before we merge this PR. Please also feedback if you need help from others. |
abdda43
to
2f0a9e1
Compare
ping @ahrtr I updated the pull request with new e2e cases. The |
2f0a9e1
to
1143e2a
Compare
1143e2a
to
c19beea
Compare
Please put all hashKV related e2e cases into a separate file, e.g. |
Discussed with @fuweid today. The existing implementation of HashByRev and Compaction are tightly coupled, and also they don't meet the expected behavior (see below). The draft expected behavior is recorded in the doc. See summary below as well. Please comment in the doc to ensure we have consensus. HashByRev (rev)
Concern Solution: use cluster-level feature-gate to resolve this concern. The fix/change will not be applied until all members have enabled the feature. CompactionWhen compacting revision X,
It means that users can start to read Revision X and watch starting from X after the compaction. Reading or Watching X-1 will get an For example, compact (9),
Next step
|
Done. PTAL,thanks |
}) | ||
} | ||
|
||
func testStartWatcherFromCompactedRevision(t *testing.T, performCompactOnTombstone bool) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function would benefit from splitting it up and cleanup, but let's not block fix on test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Nice work! @fuweid
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahrtr, fuweid, serathius The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@ahrtr Yes, I will do the backport. Thanks for the review! @ahrtr @serathius |
I see the failure below in But unfortunately, I couldn't reproduce it locally. I also manually verified the steps, and couldn't reproduce it.
|
ping @ahrtr I think it's related to github service. The test was using v3.5.0 which is not expected.
The following script can reproduce this. EXPECT_DEBUG=true MANUAL_VER=v3.5.0 TESTCASE='TestVerifyHashKVAfterCompactionOnLastTombstone_MixVersions' GO_TEST_FLAGS="-v -count=1" make test-e2e-release |
script issue? Lines 598 to 599 in b4450d5
|
It's github service issue.
The git service returns 503 so that we fallback to v3.5.0 |
I know that github wasn't stable at that time. I meant that we should fail the workflow check immediately so that it's well aware that it's github issue. cc @ivanvc |
+1 to abort test if there is something wrong during fetching latest version |
Before this patch, the tombstone can be deleted if its revision is equal compacted revision. It causes that the watch subscriber won't get this DELETE event. Based on Compact API [1], we should keep tombstone revision if it's not less than the compaction revision.
Please read https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#contribution-flow.
To Reviewers:
During writing tests, I found that the compact doesn't always remove smaller revision data.
For example,
Not sure we should fix it in the follow-up. Just want to highlight it.