showuon commented on code in PR #14161:
URL: https://github.com/apache/kafka/pull/14161#discussion_r1294147126
##########
core/src/main/scala/kafka/server/ConfigHandler.scala:
##########
@@ -62,6 +62,12 @@ class TopicConfigHandler(private val logManager: LogManager,
kafkaConfig: KafkaC
topicConfig.asScala.forKeyValue { (key, value) =>
if (!configNamesToExclude.contains(key)) props.put(key, value)
}
+
+ if (!kafkaConfig.remoteLogManagerConfig.enableRemoteStorageSystem()
+ && topicConfig.getProperty(TopicConfig.REMOTE_LOG_STORAGE_ENABLE_CONFIG)
!= null) {
Review Comment:
I'd disagree with this. Under this change, when the users set the topic
level `enable.remote.storage=false` explicitly when creating a topic. Then,
when disabling system-wide `remote.log.storage.system.enable=false` (or maybe
they didn't enable it), the next startup will fail immediately with:
```
s"You have to delete all topics with the property remote.storage.enable
(i.e. $topic) before disabling tiered storage cluster-wide"
```
That doesn't make sense to me.
If you think we should notify users about this:
```
Right now (and for 3.6) if I change enable.remote.storage from true to false
the topic will stop being archived, but the data which is already in remote
storage won't be deleted.
```
I think we can add note in docs and logs when dynamically disabled
topic-level `enable.remote.storage=false`, and make this check to `true` case.
WDYT?
--
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
