chickenchickenlove commented on PR #20969: URL: https://github.com/apache/kafka/pull/20969#issuecomment-3860130446
@lucliu1108 @mjsax @lucasbru @bbejeck Thanks for the input. Let me try to summarize my view a bit more clearly! 1. First, as @mjsax mentioned, there seems to be a mismatch between what the JavaDoc currently states and what the code actually does. So it would be good to update the JavaDoc in this PR to reflect the real behavior (or the agreed contract). 2. On whether we need a KIP, opinions seem mixed. I’m not fully certain about the “right” boundary either, but my understanding is that for changes to a public contract/interface that may affect user experience: - if it’s clearly a bug fix (i.e., the documented/expected behavior was wrong and we’re correcting it), it might be reasonable to proceed without a KIP; whereas - if it’s not a bug but an intentional contract change, then documenting it via a KIP seems safer/cleaner. So I think the key question for deciding whether a KIP is required is whether we treat the current situation as a bug or as a contract change. 3. Regarding what @lucliu1108 asked (how often this is called in production / how important the log is), it’s hard for me to validate directly since I’m not currently operating this in a production environment. However, based on my past experience, I used to run `ksqlDB` / `Kafka Streams` applications on `Kubernetes` `StatefulSet`s without `PVC`s, meaning the disk was wiped clean on each restart. In that kind of setup, this log message wasn’t particularly important. But, I think this situation is minor. That said, I think most `ksqlDB` / `Kafka Streams` users—even on Kubernetes—will try to preserve local state as much as possible using `PVC`s (often with `StatefulSet`s). So when considering stateful environments, Option (2) still seems valuable for many real-world deployments.\ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
