showuon commented on PR #16615: URL: https://github.com/apache/kafka/pull/16615#issuecomment-2238831264
From the [KIP-950](https://cwiki.apache.org/confluence/display/KAFKA/KIP-950%3A++Tiered+Storage+Disablement#KIP950:TieredStorageDisablement-Disablement-KRaftBackedCluster), when user changes `remote.storage.enable` to false, we should do: 1. The controller creates a ConfigRecord and persists it in the metadata topic. (this is done in current KRaft) 2. The controller creates a TopicRecord to increment the tiered_epoch and update the tiered_state to DISABLED state. (this should be added) 3. Broker detects the configuration change, it calls the ConfigHandler to process the ConfigRecord change with tiered storage disablement. (this is done in current KRaft) 4. The broker ConfigHandler calls RemoteLogManager#stopPartitions(). (this should be added) 5. Execution of RemoteLogManager#stopPartitions(): (this should be added) 5.1. Removes the scheduled tasks for the topic-partition from the thread pool responsible for archiving logs to remote storage. 5.2. If the disablement policy is set to delete, the Log start offset (LSO) is updated to match the Local Log Start Offset and the remote log is deleted by calling the RemoteStorageManager#deleteLogSegmentData(). 5.3. If the disablement policy is set to retain, there is no extra call required to delete remote data as the RemoteLogManager leader partition task will periodically expire segments that are earlier than the log start offset. I didn't see we do anything based on the KIP description. Could you let me know why? And how we should continue? -- 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
