Hi everyone,
I would like to start a discussion on KIP-950: Tiered Storage Disablement
(https://cwiki.apache.org/confluence/display/KAFKA/KIP-950%3A++Tiered+Storage+Disablement).
This KIP proposes adding the ability to disable and re-enable tiered storage on
a topic.
Thanks,
Mehari
Hi all,
I would like thank you all of you for participating in the voting process.
After being open for 11 days, we have received the necessary votes to proceed,
and I am now closing the voting process. KIP-937 has been accepted with 3
binding votes from Luke Chen, Divij Vaidya, and Justine
Hi Justine/All,
I want to wrap up this voting process in the next day or so. Justine, since you
gave a conditional binding vote regarding updating the error message, I want to
circle back and verify that you're happy with the current state of the changes
before concluding the voting process.
Hi Gaurav,
You have a valid concern regarding the proposed default value for
log.message.timestamp.after.max.ms being only 1 hour.
We can keep this as Long.MAX_VALUE for the first phase implementation of this
KIP and change the default value to 1 hour in future iterations. In the
meantime,
Thank you, Justin. That makes sense.
I have updated the KIP to remove the concept of ahead/behind. Instead, we will
use the existing error message that utilizes the acceptable range for the
timestamps.
Thanks,
Mehari
Hi Justine,
I have initiated the voting process for this KIP here:
https://lists.apache.org/thread/y3yfnphsmrgwfdhx3xfhjtwdb7p1dn0v
We have already received two binding votes, and I am seeking a third vote for
the adoption of the KIP.
As you have previously reviewed this KIP, would you be
Hello everyone,
I am opening the Volte on KIP-937 here. If we have more to discuss, please
continue the discussion on the existing thread at:
https://lists.apache.org/thread/wdpw845q9f5rhf6tz9tdlx3kc1g5zczc
Thank you,
Mehari
Hi Luke, Divij and All,
I have updated the KIP to incorporate Luke's comment. We now have two new
configurations for validating the message timestamp difference. The existing
configuration, "log.message.timestamp.difference.max.ms", will be deprecated.
The "before" validation uses the same
> Although it's more verbose, splitting the configuration into explicit ‘past’
> and ‘future’ would provide the appropriate tradeoff between constraint and
> flexibility, right?
+1
as a
>> config, since after this change, the root issue is still not completed
>> resolved.
>> After this KIP, the 1 hour later of timestamp can still be appended
>> successfully, which might still be an issue for some applications.
>> I'd propose to introduce 2 new configs, one i
e.
> Could we include some information on this approach and why we aren't
> pursuing it? I think message format bumps are tricky, but it is worth
> calling out that this is also an option.
>
> Thanks,
> Justine
>
> On Fri, Jun 2, 2023 at 4:51 PM Beyene, Mehari <mailto:meh
Hi Justine,
I added a section under Proposed Changes -> Timestamp Validation Logic to
capture how the INVALID_TIMESTAMP is handled in this KIP.
Please let me know if there are any additional areas you would like me to
address.
Thanks,
Mehari
the batch.
I think that if we expect to handle this case just as we do for the already
existing invalid_timestamp error, we should include some information on how
that is handled in the KIP.
Thanks,
Justine
On Tue, May 30, 2023 at 1:07 PM Beyene, Mehari mailto:meh...@amazon.com.inva>lid>
wrot
Hi Everyone,
I would like to start a discussion on KIP-937: Improve Message Timestamp
Validation
(https://cwiki.apache.org/confluence/display/KAFKA/KIP-937%3A+Improve+Message+Timestamp+Validation).
This is a small KIP that aims to tighten the current validation logic of a
message timestamp.
Hello Team,
I would like to contribute to the KIPs and I am requesting permission as
documented here:
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals#KafkaImprovementProposals-GettingStarted
Wiki ID: mehbey
Jira ID: mehbey
Thank you,
Mehari
15 matches
Mail list logo
