-
Notifications
You must be signed in to change notification settings - Fork 589
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
rptest: fix cloud start kafka offset computation #10262
rptest: fix cloud start kafka offset computation #10262
Conversation
/ci-repeat 5 |
Let's wait for the |
A lot of runs failed due to disk space. Triggering another ci-repeat...
|
/ci-repeat 5 |
770cf10
to
b3a99d5
Compare
/ci-repeat 5 |
b3a99d5
to
991e4d5
Compare
/ci-repeat 5 |
Previously, `BucketView.kafka_start_offset` computed the start Kafka offset from the manifest from the segment with the min `base_offset`. Since the manifest is allowed to have entries in 'segments' that are below 'start_offset', it broke when, in a recent change, we stopped uploading after the housekeeping. This commit fixes the failures in `CloudStorageTimingStressTest` by correcting the util function mentioned above. Cloud retention always operats on segment boundaries. There are two cases: 1. Start offset is advanced to the `base_offset` of another segment 2. Start offset is advanced to the `committed_offset + 1` of the latest segment at the time. This happens when retention decides to remove all segments from the cloud to satisfy the retention policy. Both cases are now handled correctly.
991e4d5
to
ed5ac40
Compare
/ci-repeat 5 |
The latest CI repeat was green. This is good to merge IMO. |
Previously,
BucketView.kafka_start_offset
computed the start Kafka offset from the manifest from the segment with the minbase_offset
. Since the manifest is allowed to have entries in 'segments' that are below 'start_offset', it broke when, in a recent change, we stopped uploading after the housekeeping.This commit fixes the failures in
CloudStorageTimingStressTest
by correcting the util function mentioned above. Cloud retention always operats on segment boundaries. There are two cases:base_offset
of another segmentcommited_offset + 1
of the latest segment at the time. This happens when retention decides to remove all segments from the cloud to satisfy the retention policy.Both cases are now handled correctly.
Related #10130
Fixes #10241
Backports Required
Release Notes