kamalcph commented on PR #16653: URL: https://github.com/apache/kafka/pull/16653#issuecomment-2249801286
> but I still think it's important to let users explicitly set delete on disabled, then we delete the remote data, otherwise, I can imagine some users might feel surprised(or panic) when they accidentally disable remote.storage.enable There are other topic level overrides which can cause complete data loss. (eg) configuring accidentally retention.ms=1, and retention.bytes=1. Also, other configs such as `segment.ms=1` can bring down the entire cluster. This was also discussed in the [mailing list](https://lists.apache.org/thread/3dx9mdmsqf8pko9xdmhks80k96g650zp). The `remote.storage.enable` is a topic-only config and it is not inferred from the log/broker config. If the user accidentally disables this flag on the topic then the remote logs will be deleted and only local-logs will be kept. We can document the behavior of graceful and ungraceful disablement in our docs. In your proposal, the third row might create code smell and lead to edge-cases:  For v0, we can keep ungraceful deletion as the default and provide the option to the user to disable the remote storage gracefully. In v1, we can make graceful deletion as default for remote log disablement. -- 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: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
