Hello Jun, Chia-Ping,
Thanks for the reply.
JR28:
You're right. If the user passes a null value, it will be converted to an empty
list.
I’ve updated the KIP accordingly.
JR29:
For early.start.listeners, the exception is thrown during Kafka’s internal
validation,
and it’s not caused by a null or empty list. Therefore, I think we should
set the validator to none. I’ve updated the KIP.
JR30 / chia04:
Currently, passing a null value results in a NullPointerException. I’ve updated
the KIP to reflect this behavior.
JR31:
Since the default value of plugin.path is null, it indicates that the user has
not set this configuration.
Changing it to an empty list might be confusing, as it implies the user
explicitly set the config but provided no paths.
However, if using an empty list is more appropriate for this config, I’m fine
with changing it.
We can set the default value to List.of() and disallow null values.
JR32:
An empty value for partition.assignment.strategy will result in an
IllegalStateException. I’ve updated the KIP.
chia00:
This config should not be null. I’ve updated the KIP to reflect that.
chia01 / chia02:
These configurations should be both non-null and non-empty.
I’ve updated them to only allow non-empty lists.
chia03:
Currently, passing a null value will throw a NullPointerException.
I’ve updated the KIP accordingly.
Best Regards,
Jiunn-Yang
> Chia-Ping Tsai <chia7...@gmail.com> 於 2025年7月17日 凌晨2:37 寫道：
>
> hi Jiunn-Yang,
>
> chia00. why could `bootstrap.servers` be null in StreamsConfig?
>
> chia01. the empty `task.assigned.partitions` is a bit weird. That means
> consumer has nothing to seek/poll.
>
> chia02. task.assigned.groups has analogous issue.
>
> chia03. MirrorCheckpointConfig's `groups` and `groups.exclude` should not
> accept null, since they are complied by regular expression.
>
> chia04. MirrorSourceConfig's `topics` and `topics.exclude` have similar
> issue.
>
> Best,
> Chia-Ping
>
> Jun Rao <j...@confluent.io.invalid> 於 2025年7月17日 週四 上午12:51寫道：
>
>> Hi, Jiunn-Yang,
>>
>> Thanks for the reply. A few more comments.
>>
>> JR28. AdminClientConfig: Currently, bootstrap.servers doesn't throw
>> NullPointerException on null value. It's converted to an empty list.
>>
>> JR29. The "Before exception" column: It would be useful to add which value
>> causes an exception. For example, duplicated values currently don't
>> typically cause exceptions. Also, for early.start.listeners, which value
>> causes ConfigException currently?
>>
>> JR30. Why do we allow the following to be null? In general, null only makes
>> sense if it's the default value.
>> MirrorSourceConfig: topics, topics.exclude, config.properties.exclude
>>
>> JR31. WorkerConfig: plugin.path It seems that we should allow it to be
>> empty, but not null?
>>
>> JR32. partition.assignment.strategy shouldn't be empty, right?
>>
>> Jun
>>
>> On Wed, Jul 16, 2025 at 4:32 AM 黃竣陽 <s7133...@gmail.com> wrote:
>>
>>> Hi Jun,
>>>
>>> Thanks for the reply.
>>>
>>> JR26: I’ve addressed this change in the KIP.
>>>
>>> JR27:
>>> I’ve documented the following configurations in the KIP:
>>>
>>> ConsumerConfig
>>> partition.assignment.strategy
>>>
>>> StreamsConfig
>>> bootstrap.servers
>>>
>>> MirrorCheckpointConfig
>>> groups
>>> groups.exclude
>>> task.assigned.groups
>>>
>>> MirrorSourceConfig
>>> topics
>>> topics.exclude
>>> config.properties.exclude
>>>
>>> WorkerConfig
>>> plugin.path
>>>
>>> RestServerConfig
>>> rest.extension.classes
>>>
>>> Other configurations already have default values and corresponding
>>> validators:
>>>
>>> LogConfig
>>> leader.replication.throttled.replicas: List.of() →
>>> ThrottledReplicaListValidator
>>> follower.replication.throttled.replicas: List.of() →
>>> ThrottledReplicaListValidator
>>>
>>> StreamsConfig
>>> rack.aware.assignment.tags: List.of() → atMostOfSize
>>>
>>> ConnectorConfig
>>> transforms: List.of() → aliasValidator
>>> predicates: List.of() → aliasValidator
>>>
>>> SourceConnectorConfig
>>> topic.creation.groups: List.of() → ConfigDef.CompositeValidator
>>>
>>> DistributedConfig
>>> inter.worker.verification.algorithms:
>>> defaultVerificationAlgorithms(crypto) → ConfigDef.LambdaValidator
>>>
>>> RestServerConfig
>>> admin.listeners: null → AdminListenersValidator
>>> listeners: List.of("http://:8083";) → ListenersValidator
>>>
>>> Best Regards,
>>> Jiunn-Yang
>>>
>>>> Jun Rao <j...@confluent.io.INVALID> 於 2025年7月16日 清晨7:14 寫道：
>>>>
>>>> Hi, Jiunn-Yang,
>>>>
>>>> Thanks for the reply.
>>>>
>>>> JR 26. early.start.listeners and interceptor.classes: It seems that
>> both
>>>> could be empty?
>>>>
>>>> JR27. The following configs of type LIST are missing.
>>>>
>>>> ConsumerConfig
>>>> partition.assignment.strategy
>>>>
>>>> BrokerSecurityConfigs
>>>>
>>>> QuorumConfig
>>>>
>>>> LogConfig
>>>> leader.replication.throttled.replicas
>>>> follower.replication.throttled.replicas
>>>>
>>>> StreamsConfig
>>>> rack.aware.assignment.tags
>>>> bootstrap.servers
>>>>
>>>> MirrorCheckpointConfig
>>>> groups
>>>> groups.exclude
>>>>
>>>> MirrorCheckpointConfig
>>>> task.assigned.groups
>>>>
>>>> MirrorSourceConfig
>>>> topics
>>>> topics.exclude
>>>> config.properties.exclude
>>>>
>>>> ConnectorConfig
>>>> transforms
>>>> predicates
>>>>
>>>> SourceConnectorConfig
>>>> topic.creation.groups
>>>>
>>>> WorkerConfig
>>>> plugin.path
>>>>
>>>> DistributedConfig
>>>> inter.worker.verification.algorithms
>>>>
>>>> RestServerConfig
>>>> rest.extension.classes
>>>> admin.listeners
>>>> listeners
>>>>
>>>> Thanks,
>>>>
>>>> Jun
>>>>
>>>> On Tue, Jul 15, 2025 at 6:22 AM 黃竣陽 <s7133...@gmail.com> wrote:
>>>>
>>>>> Hello Jun Chia,
>>>>>
>>>>> Thanks for the reply,
>>>>>
>>>>> JR20: This configuration should remain unchanged. I have updated the
>>> KIP.
>>>>>
>>>>> JR21: For both Consumer and Producer, the default value is an empty
>>> list,
>>>>> and the
>>>>> validator used is NonNullValidator. I think we can change the
>> validator
>>> to
>>>>> ValidList.anyNonDuplicateValues
>>>>> with isNullAllowed = false and isEmptyAllowed = false.
>>>>>
>>>>> JR23: I’ve addressed this change in the KIP. Although the default
>> value
>>> of
>>>>> early.start.listeners remains
>>>>> unchanged, the validator now disallows empty lists.
>>>>>
>>>>> JR24: Since log.dirs does not change its default value, I used a dash
>>> (-)
>>>>> to indicate that the field remains unchanged.
>>>>>
>>>>> JR25: I’ve updated the table and aligned similar validators as much as
>>>>> possible for consistency.
>>>>>
>>>>> Best Regards,
>>>>> Jiunn-Yang
>>>>>
>>>>>> Chia-Ping Tsai <chia7...@gmail.com> 於 2025年7月15日 下午2:12 寫道：
>>>>>>
>>>>>>> JR20. controller.listener.names : It's required on the broker. Is it
>>>>>> required on the controller?
>>>>>>
>>>>>> there is a small "sugar" in the controller, which we will
>>>>>> create listener.security.protocol.map based on
>>> controller.listener.names
>>>>>> if listener.security.protocol.map is not explicitly set [0]
>>>>>> Additionally, `controller.listener.names` is also used to filter out
>>> the
>>>>>> advertised controller listeners [1]
>>>>>>
>>>>>>
>>>>>>> JR22. group.coordinator.rebalance.protocols: Currently, it can be
>> set
>>> to
>>>>>> null, right?
>>>>>>
>>>>>> I don't think so. There is no null check after calling
>>>>>>
>>>>>
>>>
>> `getList(GroupCoordinatorConfig.GROUP_COORDINATOR_REBALANCE_PROTOCOLS_CONFIG)`[2],
>>>>>> which causes an NPE if getList returns null."
>>>>>>
>>>>>> [0]
>>>>>>
>>>>>
>>>
>> https://github.com/apache/kafka/blob/trunk/server/src/main/java/org/apache/kafka/server/config/AbstractKafkaConfig.java#L133
>>>>>> [1]
>>>>>>
>>>>>
>>>
>> https://github.com/apache/kafka/blob/7ea32a0e938c22119f11908aa419aaf0ffd9b6d8/core/src/main/scala/kafka/server/KafkaConfig.scala#L459
>>>>>> [2]
>>>>>>
>>>>>
>>>
>> https://github.com/apache/kafka/blob/7ea32a0e938c22119f11908aa419aaf0ffd9b6d8/core/src/main/scala/kafka/server/KafkaConfig.scala#L373
>>>>>>
>>>>>> Jun Rao <j...@confluent.io.invalid> 於 2025年7月15日 週二 上午6:20寫道：
>>>>>>
>>>>>>> Hi, Jiunn-Yang,
>>>>>>>
>>>>>>> Thanks for the updated KIP.
>>>>>>>
>>>>>>> JR20. controller.listener.names : It's required on the broker. Is it
>>>>>>> required on the controller?
>>>>>>>
>>>>>>> JR21. bootstrap.servers: Some of them (e.g. in producer/consumer)
>>>>> already
>>>>>>> require it to be non-null.
>>>>>>>
>>>>>>> JR22. group.coordinator.rebalance.protocols: Currently, it can be
>> set
>>> to
>>>>>>> null, right?
>>>>>>>
>>>>>>> JR23. early.start.listeners: It allows default value of null, which
>>>>> means
>>>>>>> that all listeners included in controller.listener.names will also
>> be
>>>>> early
>>>>>>> start listeners.
>>>>>>>
>>>>>>> JR24. log.dirs: It currently has a default value of null.
>>>>>>>
>>>>>>> JR25. It seems there are quite a few more configs of type list. Do
>>> they
>>>>>>> need to be changed too?
>>>>>>>
>>>>>>> AdminClientConfig: 4
>>>>>>> ConsumerConfig: 5
>>>>>>> ProducerConfig: 4
>>>>>>> SaslConfigs: 1
>>>>>>> SslConfigs: 2
>>>>>>> BrokerSecurityConfigs: 5
>>>>>>> MirrorClientConfig: 1
>>>>>>> org.apache.kafka.connect.mirror : 16
>>>>>>> org.apache.kafka.connect.runtime : 21
>>>>>>> GroupCoordinatorConfig: 3
>>>>>>> QuorumConfig: 2
>>>>>>> ServerConfigs: 1
>>>>>>> KRaftConfigs: 1
>>>>>>> ClientMetricsConfigs: 2
>>>>>>> MetricConfigs: 2
>>>>>>> LogConfig: 4
>>>>>>> StreamsConfig: 4
>>>>>>>
>>>>>>> Jun
>>>>>>>
>>>>>>> On Fri, Jul 11, 2025 at 8:13 PM 黃竣陽 <s7133...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Chia, Jun
>>>>>>>>
>>>>>>>> Thanks for the reply,
>>>>>>>> I have updated the table in the KIP.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Jiunn-Yang
>>>>>>>>
>>>>>>>>> Chia-Ping Tsai <chia7...@gmail.com> 於 2025年7月11日 清晨7:38 寫道：
>>>>>>>>>
>>>>>>>>> Hi, Jun
>>>>>>>>>
>>>>>>>>> Thanks for the reply.
>>>>>>>>>
>>>>>>>>> I think the following configs could use null as the default value
>>> and
>>>>>>>> treat
>>>>>>>>> an "empty list" as an illegal value.
>>>>>>>>>
>>>>>>>>> `sasl.oauthbearer.expected.audience`, `ssl.cipher.suites`,
>>>>>>>>> `ssl.enabled.protocols`,
>>>>>>>>> and `log.dirs`
>>>>>>>>>
>>>>>>>>> Jun Rao <j...@confluent.io.invalid> 於 2025年7月11日 週五 上午6:59寫道：
>>>>>>>>>
>>>>>>>>>> Hi, Chia-Ping, Jiunn-Yang,
>>>>>>>>>>
>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>
>>>>>>>>>> As you said, if ssl.cipher.suites is empty, intuitively this
>> means
>>>>>>> that
>>>>>>>> no
>>>>>>>>>> cipher is allowed. So, this should be an illegal config. It just
>>>>>>> happens
>>>>>>>>>> that our implementation treats it as if the config is not set
>>>>> (meaning
>>>>>>>> the
>>>>>>>>>> value is null). So, it seems that a more intuitive convention is:
>>> if
>>>>>>> the
>>>>>>>>>> config is not set, it defaults to all available cipher suites. If
>>>>> it's
>>>>>>>>>> explicitly set, it can't be empty.
>>>>>>>>>>
>>>>>>>>>> Jun
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 9, 2025 at 8:27 AM 黃竣陽 <s7133...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi Jun, Chia
>>>>>>>>>>>
>>>>>>>>>>>>> Also, it would be useful to add a compatibility column in the
>>>>>>> table.
>>>>>>>>>> If
>>>>>>>>>>> a
>>>>>>>>>>>>> value is formally disallowed, it would be useful to compare
>> the
>>>>> old
>>>>>>>>>> and
>>>>>>>>>>> the
>>>>>>>>>>>>> new behavior (e.g. a different exception is thrown, etc).
>>>>>>>>>>> I’ve updated the table to show which exceptions will be thrown
>> for
>>>>>>> each
>>>>>>>>>>> behavior.
>>>>>>>>>>>
>>>>>>>>>>>>>> I don't understand the point of "5.0". Could you please share
>>>>> more
>>>>>>>>>>> details?
>>>>>>>>>>>>>> It seems to me changing the type or default value should be
>>> fine
>>>>>>> in
>>>>>>>>>>> minor
>>>>>>>>>>>>>> release if we don't break the existing property files.
>>>>>>>>>>> I don't think this requires any compatibility considerations, so
>>>>> I’ve
>>>>>>>>>>> removed the Kafka 5.0 changes section.
>>>>>>>>>>>
>>>>>>>>>>>>>> `max.connections.per.ip.overrides` is parsed as "map" type,
>> so
>>>>>>> using
>>>>>>>>>>> `LIST`
>>>>>>>>>>>>>> instead of `String` does not seems to make sense.
>>>>>>>>>>> I have removed the config from KIP
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>
>>>>>>>>>>>> Chia-Ping Tsai <chia7...@apache.org> 於 2025年7月9日 晚上10:26 寫道：
>>>>>>>>>>>>
>>>>>>>>>>>>> For ssl.cipher.suites, changing the default value from null to
>>>>>>> empty
>>>>>>>>>> is
>>>>>>>>>>>>> actually a breaking change. According to the doc, null means
>>> that
>>>>>>> all
>>>>>>>>>>> the
>>>>>>>>>>>>> available cipher suites are supported. I am thinking that we
>>>>> should
>>>>>>>>>>>>> continue to allow null as the default since it could
>> represent a
>>>>>>>> state
>>>>>>>>>>>>> different from empty.
>>>>>>>>>>>>
>>>>>>>>>>>> "Empty list" seems to be a weird case. It appears to signify
>> that
>>>>> no
>>>>>>>>>>> cipher suites are accepted. However, in the codebase, an empty
>>> list
>>>>>>> is
>>>>>>>>>>> handled as if all available cipher suites are supported [0]. We
>>>>>>> should
>>>>>>>>>> not
>>>>>>>>>>> support the case of "no supported cipher suite," as it doesn't
>>> make
>>>>>>>>>> sense.
>>>>>>>>>>>>
>>>>>>>>>>>> In short, changing the default value from null to empty does
>> not
>>>>>>> break
>>>>>>>>>>> the behavior.
>>>>>>>>>>>>
>>>>>>>>>>>> [0]
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>> https://github.com/apache/kafka/blob/dabde76ebf105aaa945db60b7753331c83a8c989/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L139
>>>>>>>>>>>>
>>>>>>>>>>>> On 2025/07/08 17:01:07 Jun Rao wrote:
>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I agree with Chia-Ping. If we allow cleanup.policy to be
>> empty,
>>> we
>>>>>>>>>> will
>>>>>>>>>>>>> just continue to allow it in all future releases.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For ssl.cipher.suites, changing the default value from null to
>>>>>>> empty
>>>>>>>>>> is
>>>>>>>>>>>>> actually a breaking change. According to the doc, null means
>>> that
>>>>>>> all
>>>>>>>>>>> the
>>>>>>>>>>>>> available cipher suites are supported. I am thinking that we
>>>>> should
>>>>>>>>>>>>> continue to allow null as the default since it could
>> represent a
>>>>>>>> state
>>>>>>>>>>>>> different from empty.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, it would be useful to add a compatibility column in the
>>>>>>> table.
>>>>>>>>>> If
>>>>>>>>>>> a
>>>>>>>>>>>>> value is formally disallowed, it would be useful to compare
>> the
>>>>> old
>>>>>>>>>> and
>>>>>>>>>>> the
>>>>>>>>>>>>> new behavior (e.g. a different exception is thrown, etc).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Jul 8, 2025 at 8:36 AM Chia-Ping Tsai <
>>> chia7...@gmail.com
>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> hi Jiunn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the explanation. I have updated the KIP
>> accordingly:
>>>>> in
>>>>>>>>>>> Kafka
>>>>>>>>>>>>>>> 4.x, cleanup.policy
>>>>>>>>>>>>>>> can be set to an empty list with a warning message emitted;
>>>>>>>> however,
>>>>>>>>>>> in
>>>>>>>>>>>>>>> Kafka 5.0, setting an
>>>>>>>>>>>>>>> empty list for cleanup.policy will no longer be allowed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If we agree to support "empty list", the approach of "none"
>>> could
>>>>>>> be
>>>>>>>>>>>>>> eliminated, right?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't understand the point of "5.0". Could you please share
>>>>> more
>>>>>>>>>>> details?
>>>>>>>>>>>>>> It seems to me changing the type or default value should be
>>> fine
>>>>>>> in
>>>>>>>>>>> minor
>>>>>>>>>>>>>> release if we don't break the existing property files.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> `max.connections.per.ip.overrides` is parsed as "map" type,
>> so
>>>>>>> using
>>>>>>>>>>> `LIST`
>>>>>>>>>>>>>> instead of `String` does not seems to make sense.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>> Chia-Ping
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 黃竣陽 <s7133...@gmail.com> 於 2025年7月8日 週二 下午11:25寫道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Null could make sense as the default value, but it just
>>> means
>>>>>>>> that
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> config key is not set explicitly.
>>>>>>>>>>>>>>>>> Given that, it's probably simpler to just allow
>>>>>>>>>>>>>>>>> log.cleanup.policy to be empty and properly support it?
>>>>>>>>>>>>>>> Thanks for the explanation. I have updated the KIP
>>> accordingly:
>>>>>>> in
>>>>>>>>>>> Kafka
>>>>>>>>>>>>>>> 4.x, cleanup.policy
>>>>>>>>>>>>>>> can be set to an empty list with a warning message emitted;
>>>>>>>> however,
>>>>>>>>>>> in
>>>>>>>>>>>>>>> Kafka 5.0, setting an
>>>>>>>>>>>>>>> empty list for cleanup.policy will no longer be allowed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For another, there is an additional issue which could be
>>>>> handled
>>>>>>>> by
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> KIP. Some configs have "string" type, but they are handled
>>> as a
>>>>>>>>>> LIST.
>>>>>>>>>>>>>> For
>>>>>>>>>>>>>>>> example, `early.start.listeners`, `security.providers`.
>> Could
>>>>> we
>>>>>>>>>>> change
>>>>>>>>>>>>>>>> their type to LIST to benefit from this KIP? I mean to make
>>>>> them
>>>>>>>>>>>>>>>> non-nullable.
>>>>>>>>>>>>>>> I have also updated the KIP to include the tables detailing
>>> the
>>>>>>>>>>> changes
>>>>>>>>>>>>>>> for LIST-type configuration
>>>>>>>>>>>>>>> default values and the migration from STRING-type to
>> LIST-type
>>>>>>>>>>>>>>> configurations.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Chia-Ping Tsai <chia7...@gmail.com> 於 2025年7月8日 清晨7:06 寫道：
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> hi all,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> JR11. There is an existing config interceptor.classes that
>>>>>>> allows
>>>>>>>>>> an
>>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>> list and it makes intuitive sense. So, it seems that it's
>> ok
>>>>> to
>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>>> empty lists in general. Given that, it's probably simpler
>> to
>>>>>>> just
>>>>>>>>>>>>>> allow
>>>>>>>>>>>>>>>>> log.cleanup.policy to be empty and properly support it?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> yes, that is what I meant before. Additionally, the `LIST`
>>> type
>>>>>>>>>>> should
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>> accept "null". Instead, we should use an empty list as the
>>>>>>> default
>>>>>>>>>>>>>> value.
>>>>>>>>>>>>>>>> For example, `sasl.oauthbearer.expected.audience` should
>>> never
>>>>>>> has
>>>>>>>>>>>>>> "null"
>>>>>>>>>>>>>>>> value. That could eliminate the null check.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For another, there is an additional issue which could be
>>>>> handled
>>>>>>>> by
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>> KIP. Some configs have "string" type, but they are handled
>>> as a
>>>>>>>>>> LIST.
>>>>>>>>>>>>>> For
>>>>>>>>>>>>>>>> example, `early.start.listeners`, `security.providers`.
>> Could
>>>>> we
>>>>>>>>>>> change
>>>>>>>>>>>>>>>> their type to LIST to benefit from this KIP? I mean to make
>>>>> them
>>>>>>>>>>>>>>>> non-nullable.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>> Chia-Ping
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jun Rao <j...@confluent.io.invalid> 於 2025年7月8日 週二
>> 上午5:56寫道：
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> JR10. Regarding supporting the null value, I am not sure
>> how
>>>>>>> one
>>>>>>>>>>> could
>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>>> a null value in a config file. For example, if you set the
>>>>>>>>>> following
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> config file.
>>>>>>>>>>>>>>>>> configkey=
>>>>>>>>>>>>>>>>> The value of configkey will be an empty list, instead of
>>> null,
>>>>>>>>>>> right?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Null could make sense as the default value, but it just
>>> means
>>>>>>>> that
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> config key is not set explicitly.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> JR11. There is an existing config interceptor.classes that
>>>>>>> allows
>>>>>>>>>> an
>>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>> list and it makes intuitive sense. So, it seems that it's
>> ok
>>>>> to
>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>>>> empty lists in general. Given that, it's probably simpler
>> to
>>>>>>> just
>>>>>>>>>>>>>> allow
>>>>>>>>>>>>>>>>> log.cleanup.policy to be empty and properly support it?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Jul 4, 2025 at 5:13 AM 黃竣陽 <s7133...@gmail.com>
>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hello Jun,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> JR10: The sasl.oauthbearer.expected.audience is optional,
>>>>> that
>>>>>>>> is
>>>>>>>>>>>>>>> right,
>>>>>>>>>>>>>>>>>> so I think
>>>>>>>>>>>>>>>>>> that we can allow null value, but not allow the empty
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> JR11: In this KIP, the goal is to address configurations
>>> that
>>>>>>>>>>> should
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>> accept empty arrays.
>>>>>>>>>>>>>>>>>> We want to prevent users from passing in an empty list
>> when
>>>>>>> it's
>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>> valid. I believe there are two
>>>>>>>>>>>>>>>>>> main scenarios to consider:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1. Nullable but not empty:
>>>>>>>>>>>>>>>>>> The parameter allows either a null value or a non-empty
>>> list.
>>>>>>> In
>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> case,
>>>>>>>>>>>>>>>>>> if the user provides an empty list, we should throw a
>>>>>>>>>>>>>> ConfigException.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 2. Non-null and non-empty only: The parameter must always
>>>>>>>>>> contain a
>>>>>>>>>>>>>>>>>> non-empty list — null is also
>>>>>>>>>>>>>>>>>> invalid. In this case, if the user provides either a null
>>> or
>>>>>>> an
>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>>> list, we should throw a ConfigException.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Therefore, I want to prevent scenarios where users can
>> pass
>>>>> in
>>>>>>>> an
>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>>> list.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> JR12: I’ve updated NonEmptyListValidator to include an
>>>>>>> allowNull
>>>>>>>>>>>>>>>>> property.
>>>>>>>>>>>>>>>>>> This allows us to specify
>>>>>>>>>>>>>>>>>> whether a configuration permits null values or not.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> JR13: I have updated the table
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jun Rao <j...@confluent.io.INVALID> 於 2025年7月1日 清晨6:30
>> 寫道：
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sorry for the late reply. A few more comments.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JR10. The doc for sasl.oauthbearer.expected.audience
>> says
>>>>>>> that
>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>> optional. So an empty list seems to be valid.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JR11. Thinking a bit more. If we are going to support
>>> empty
>>>>>>>>>> lists
>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> general, it's probably more consistent to just allow
>>>>>>>>>>>>>>> log.cleanup.policy
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> be empty as Luke suggested, instead of introducing a new
>>>>>>> option
>>>>>>>>>>>>>> None.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JR12. NonEmptyListValidator allows the input to be null.
>>> It
>>>>>>>>>> seems
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> only ssl.cipher.suites allows null. The remaining ones
>>>>>>>> shouldn't
>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> null.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JR13. The table is very helpful. Could you also describe
>>> the
>>>>>>>>>>> old/new
>>>>>>>>>>>>>>>>>>> behavior for each config with an empty list or duplicate
>>>>>>> entry?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon, Jun 30, 2025 at 6:02 AM 黃竣陽 <s7133...@gmail.com
>>>
>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hello all,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I am manually bumping this thread. Any feedback would
>> be
>>>>>>>>>>>>>> appreciated.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 黃竣陽 <s7133...@gmail.com> 於 2025年5月28日 晚上11:21 寫道：
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hello Jun,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I have updated the KIP and introduced a new validator,
>>>>>>>>>>>>>>>>>>>> NonEmptyListValidator, which ensures that the
>>>>>>>>>>>>>>>>>>>>> provided list is either null or a non-empty list
>> without
>>>>>>>>>>> duplicate
>>>>>>>>>>>>>>>>>>>> entries. I’ve also listed the configurations that will
>>>>>>>>>>>>>>>>>>>>> be validated using this logic. Please feel free to
>> share
>>>>>>> any
>>>>>>>>>>>>>>> feedback
>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Jun Rao <j...@confluent.io.INVALID> 於 2025年5月23日
>> 凌晨2:29
>>>>>>> 寫道：
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It seems there are quite a few other configs of type
>>> list
>>>>>>>>>> (e.g.
>>>>>>>>>>>>>>>>>> several
>>>>>>>>>>>>>>>>>>>> SSL
>>>>>>>>>>>>>>>>>>>>>> related ones). It would be useful to understand if
>>> empty
>>>>>>>>>> lists
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> valid
>>>>>>>>>>>>>>>>>>>>>> for them or not.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Tue, May 13, 2025 at 10:12 AM Jun Rao <
>>>>>>> j...@confluent.io>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi, Luke,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> "My thought is that this behavior has been existed
>>>>>>>>>>>>>>>>>>>>>>> for years (maybe after "cleanup.policy" was
>>>>> introduced?),
>>>>>>>>>>> there
>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>> users relying on the empty cleanup.policy for a long
>>>>>>> time.
>>>>>>>> "
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> If you do a google search on "kafka infinite
>>> retention",
>>>>>>>> you
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>>>>>>> links like
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>> https://stackoverflow.com/questions/39735036/make-kafka-topic-log-retention-permanent
>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>> https://www.reddit.com/r/apachekafka/comments/mpz4bp/kafka_retention_question/
>>>>>>>>>>>>>>>>>>>> ,
>>>>>>>>>>>>>>>>>>>>>>> both pointing to setting the retention time and
>>>>> retention
>>>>>>>>>> size
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> -1
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> achieve this goal. So, it seems that if a user
>>>>>>>> intentionally
>>>>>>>>>>>>>> wants
>>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>>>>> retention, it's more likely they will use that
>>> approach
>>>>>>>>>>> instead
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>> setting
>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy to empty. On the other hand, our
>>>>> API/tools
>>>>>>>>>> make
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> possible
>>>>>>>>>>>>>>>>>>>>>>> for users to make a mistake by inadvertently leaving
>>> the
>>>>>>>>>>> config
>>>>>>>>>>>>>>>>> value
>>>>>>>>>>>>>>>>>>>> empty.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Mon, May 12, 2025 at 11:38 PM Luke Chen <
>>>>>>>>>> show...@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hi Jun,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Regarding the motivation, currently, we never
>>>>>>> documented
>>>>>>>>>>> that
>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy implies infinite retention. In fact,
>>> if
>>>>>>> one
>>>>>>>>>>>>>> leaves
>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy empty, it actually breaks remote
>>> storage
>>>>>>>>>> since
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>> stop
>>>>>>>>>>>>>>>>>>>>>>>> the cleaning based on local retention size and time
>>>>> too.
>>>>>>>>>> So,
>>>>>>>>>>>>>>>>> leaving
>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy empty is probably more like a user
>>>>>>> mistake
>>>>>>>>>>> than
>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>> intentional choice. Based on this assumption, the
>>> idea
>>>>>>>>>> behind
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> KIP
>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> fail an empty cleanup.policy so that the user is
>>> aware
>>>>>>> of
>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> likely
>>>>>>>>>>>>>>>>>>>>>>>> mistake and provide a new option None for users
>>> wanting
>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>> retention
>>>>>>>>>>>>>>>>>>>>>>>> to opt in explicitly.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> While we never documented the empty cleanup.policy
>>>>>>> implies
>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>>>>>> retention, we also never documented (or failed) the
>>>>>>> empty
>>>>>>>>>>>>>>>>>>>> cleanup.policy
>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>> an invalid configuration. My thought is that this
>>>>>>> behavior
>>>>>>>>>>> has
>>>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>>>>>>>>>>> existed
>>>>>>>>>>>>>>>>>>>>>>>> for years (maybe after "cleanup.policy" was
>>>>>>> introduced?),
>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>> users relying on the empty cleanup.policy for a
>> long
>>>>>>> time.
>>>>>>>>>> It
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>> good
>>>>>>>>>>>>>>>>>>>>>>>> to break the backward compatibility in a minor
>>> release
>>>>>>>>>>> version
>>>>>>>>>>>>>>>>> (ex:
>>>>>>>>>>>>>>>>>>>>>>>> v4.1.0). Even though we think we are fixing a long
>>>>>>>> existing
>>>>>>>>>>>>>> bug,
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> could
>>>>>>>>>>>>>>>>>>>>>>>> be a surprise to users.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We could also consider supporting an empty
>>>>>>> cleanup.policy
>>>>>>>>>> by
>>>>>>>>>>>>>>>>> fixing
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> issue in remote storage. But then the user may
>> never
>>>>>>>>>> realize
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Good point! I agree we need to fix it!
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hi Chia-Ping,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We can print warnings for empty cleanup.policy in
>>> 4.x
>>>>>>> and
>>>>>>>>>> in
>>>>>>>>>>>>>> 5.0
>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>> throw
>>>>>>>>>>>>>>>>>>>>>>>> exception directly to make it fail fast
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> This suggestion looks good to me!
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thank you.
>>>>>>>>>>>>>>>>>>>>>>>> Luke
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Tue, May 13, 2025 at 2:14 PM Chia-Ping Tsai <
>>>>>>>>>>>>>>>>> chia7...@apache.org
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Given Luke mentioned the existence of use cases,
>> it
>>> is
>>>>>>>>>> worth
>>>>>>>>>>>>>>>>>>>> considering
>>>>>>>>>>>>>>>>>>>>>>>>> the compatibility issue. In fact, I had previously
>>>>>>>>>>> encountered
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>>>>>>>>>> case but advised customers to utilize retention
>>>>>>>>>>> configurations
>>>>>>>>>>>>>>>>>>>> instead.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> We could also consider supporting an empty
>>>>>>>> cleanup.policy
>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>> fixing
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> issue in remote storage. But then the user may
>>> never
>>>>>>>>>>> realize
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>>>> it's a
>>>>>>>>>>>>>>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Good catch! The "empty" or "none" wouldn't make
>>> sense
>>>>>>> for
>>>>>>>>>>>>>> remote
>>>>>>>>>>>>>>>>>>>>>>>> storage.
>>>>>>>>>>>>>>>>>>>>>>>>> I've opened KAFKA-19273 to ensure topics with
>> tiered
>>>>>>>>>> storage
>>>>>>>>>>>>>> use
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> valid
>>>>>>>>>>>>>>>>>>>>>>>>> delete policy.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>>>>>> Chia-Ping
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 2025/05/12 19:06:10 Jun Rao wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Luke,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Regarding the motivation, currently, we never
>>>>>>> documented
>>>>>>>>>>> that
>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy implies infinite retention. In
>> fact,
>>>>> if
>>>>>>>>>> one
>>>>>>>>>>>>>>>>> leaves
>>>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy empty, it actually breaks remote
>>>>>>> storage
>>>>>>>>>>> since
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>>> stop
>>>>>>>>>>>>>>>>>>>>>>>>>> the cleaning based on local retention size and
>> time
>>>>>>> too.
>>>>>>>>>>> So,
>>>>>>>>>>>>>>>>>> leaving
>>>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy empty is probably more like a user
>>>>>>>> mistake
>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>> intentional choice. Based on this assumption, the
>>>>> idea
>>>>>>>>>>> behind
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> KIP
>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>> fail an empty cleanup.policy so that the user is
>>>>> aware
>>>>>>>> of
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> likely
>>>>>>>>>>>>>>>>>>>>>>>>>> mistake and provide a new option None for users
>>>>>>> wanting
>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>>>>>>> retention
>>>>>>>>>>>>>>>>>>>>>>>>>> to opt in explicitly.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> We could also consider supporting an empty
>>>>>>>> cleanup.policy
>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>> fixing
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> issue in remote storage. But then the user may
>>> never
>>>>>>>>>>> realize
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>>>> it's a
>>>>>>>>>>>>>>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, May 11, 2025 at 7:53 PM Luke Chen <
>>>>>>>>>>> show...@gmail.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the KIP.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Comments:
>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. "it is acceptable because an empty
>>> cleanup.policy
>>>>>>> is
>>>>>>>>>>>>>>>>>> considered
>>>>>>>>>>>>>>>>>>>>>>>>> invalid
>>>>>>>>>>>>>>>>>>>>>>>>>>> in Kafka. Therefore, this trade-off is
>> justified."
>>>>>>>>>>>>>>>>>>>>>>>>>>> Could you explain more about this? Why is this
>>>>>>>> trade-off
>>>>>>>>>>>>>>>>>> justified?
>>>>>>>>>>>>>>>>>>>>>>>>>>> If we think the empty cleanup.policy is invalid
>> in
>>>>>>>>>> kafka,
>>>>>>>>>>>>>> why
>>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>> provide
>>>>>>>>>>>>>>>>>>>>>>>>>>> an additional "none" option to users in this
>> KIP?
>>>>>>>>>>>>>>>>>>>>>>>>>>> FYI, there are indeed use cases that need to
>> keep
>>>>> all
>>>>>>>>>>>>>> history
>>>>>>>>>>>>>>>>>> data
>>>>>>>>>>>>>>>>>>>>>>>>> without
>>>>>>>>>>>>>>>>>>>>>>>>>>> a cleanup policy.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. Following (1), I agree we should fail fast
>> for
>>>>>>> empty
>>>>>>>>>>>>>>>>>>>>>>>>>>> "group.coordinator.rebalance.protocols" and
>>>>>>>>>>> "process.roles"
>>>>>>>>>>>>>>>>>> configs
>>>>>>>>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>>>>>>>>>> they are invalid.
>>>>>>>>>>>>>>>>>>>>>>>>>>> But about "cleanup.policy", I don't see a
>>> persuasive
>>>>>>>>>>> reason
>>>>>>>>>>>>>>> why
>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>>>>>>>> break backward compatibility to change it.
>>>>>>>>>>>>>>>>>>>>>>>>>>> "This provides a clear and direct way to
>> configure
>>>>>>>> Kafka
>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> retain
>>>>>>>>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>>>>>>>>>> log
>>>>>>>>>>>>>>>>>>>>>>>>>>> segments without any automatic cleanup."
>>>>>>>>>>>>>>>>>>>>>>>>>>> This is the motivation we mentioned in the KIP,
>>> but
>>>>>>> to
>>>>>>>>>> me,
>>>>>>>>>>>>>>>>>> backward
>>>>>>>>>>>>>>>>>>>>>>>>>>> compatibility is much more important than "a
>> clear
>>>>>>> and
>>>>>>>>>>>>>> direct
>>>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> config
>>>>>>>>>>>>>>>>>>>>>>>>>>> kafka".
>>>>>>>>>>>>>>>>>>>>>>>>>>> Do we really have to change the "cleanup.policy"
>>>>>>>> config?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Luke
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, May 7, 2025 at 2:17 AM Jun Rao
>>>>>>>>>>>>>>>>> <j...@confluent.io.invalid
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the updated KIP. It looks good to
>> me.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, May 6, 2025 at 4:58 AM 黃竣陽 <
>>>>>>>> s7133...@gmail.com
>>>>>>>>>>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Jun, chia
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for all the comments. They have all
>> been
>>>>>>>>>>> addressed
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>> updated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KIP.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I've removed all deprecated-related sections.
>>>>>>>>>>>>>> Additionally,
>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>> exception
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will now be thrown if a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> developer passes an empty validStrings list to
>>> the
>>>>>>>>>>>>>>> inNonEmpty
>>>>>>>>>>>>>>>>>>>>>>>>> method.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Chia-Ping Tsai <chia7...@gmail.com> 於
>>> 2025年5月6日
>>>>>>>>>>> 凌晨12:46
>>>>>>>>>>>>>>> 寫道：
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hi Jiunn-Yang
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The `inNonEmpty` is used to prevent users
>> pass
>>>>>>> empty
>>>>>>>>>>>>>>> config,
>>>>>>>>>>>>>>>>>>>>>>>> so
>>>>>>>>>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be non-empty too?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For example, `inNonEmpty()` should throw
>>>>> exception
>>>>>>>>>>>>>>> directly.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Chia-Ping
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun Rao <j...@confluent.io.invalid> 於
>> 2025年5月6日
>>>>> 週二
>>>>>>>>>>>>>>>>> 上午12:28寫道：
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the reply. There are still
>>> references
>>>>>>> to
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> deprecated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "stop relying on the deprecated methods"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Finally, the deprecated method will be
>>> removed
>>>>>>> in
>>>>>>>>>>> Kafka
>>>>>>>>>>>>>>>>> 5.0"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, May 3, 2025 at 7:42 AM 黃竣陽 <
>>>>>>>>>>> s7133...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Jun, chia,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for all the comments. They have all
>>> been
>>>>>>>>>>>>>> addressed
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> updated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KIP.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Chia-Ping Tsai <chia7...@gmail.com> 於
>>>>>>> 2025年5月3日
>>>>>>>>>>>>>> 凌晨2:03
>>>>>>>>>>>>>>>>> 寫道：
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hi Jiunn-Yang
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in the "Compatibility, Deprecation, and
>>>>>>> Migration
>>>>>>>>>>>>>> Plan",
>>>>>>>>>>>>>>>>>>>>>>>>> could you
>>>>>>>>>>>>>>>>>>>>>>>>>>>> add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> description to remind readers that
>>>>>>>> "clean.policy="
>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>>>> replaced
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "clean.policy=none" if they do want to
>>> disable
>>>>>>>>>>> delete
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> compact.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Chia-Ping
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun Rao <j...@confluent.io.invalid> 於
>>>>> 2025年5月3日
>>>>>>>> 週六
>>>>>>>>>>>>>>>>>>>>>>>> 上午1:55寫道：
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It's fine not to deprecate ValidList#in
>> for
>>>>>>> now.
>>>>>>>>>>>>>> Could
>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>>>>> update
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> KIP
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> completely? There are still references to
>>>>>>>>>>>>>> deprecation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 2, 2025 at 4:59 AM 黃竣陽 <
>>>>>>>>>>>>>> s7133...@gmail.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Jun,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I don’t think we should deprecate the
>>>>>>>>>> ValidList#in
>>>>>>>>>>>>>>>>>>>>>>>> method,
>>>>>>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> may
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> future scenarios where we want
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to allow list configs to be empty. It’s
>>>>>>> useful
>>>>>>>>>> to
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>> both
>>>>>>>>>>>>>>>>>>>>>>>>>>>> methods:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (which allows empty lists)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and inNonEmpty (which enforces non-empty
>>>>>>>> lists).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Just a minor comment. It would be
>> useful
>>> to
>>>>>>>>>>>>>> document
>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>> during
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> upgrade,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if cleanup.policy is empty, the broker
>>> will
>>>>>>>>>> fail
>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> start.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I’ve updated the KIP accordingly.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun Rao <j...@confluent.io.INVALID> 於
>>>>>>>> 2025年5月2日
>>>>>>>>>>>>>>>>> 凌晨12:50
>>>>>>>>>>>>>>>>>>>>>>>> 寫道：
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the reply. Sounds good.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Just a minor comment. It would be
>> useful
>>> to
>>>>>>>>>>>>>> document
>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>> during
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> upgrade,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if cleanup.policy is empty, the broker
>>> will
>>>>>>>>>> fail
>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> start.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, May 1, 2025 at 8:40 AM 黃竣陽 <
>>>>>>>>>>>>>>>>> s7133...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hello Jun,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since ValidList is a public API, we
>> need
>>>>> to
>>>>>>>>>>>>>> maintain
>>>>>>>>>>>>>>>>>>>>>>>>> backward
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compatibility. Therefore, the
>>>>>>> isEmptyAllowed
>>>>>>>>>>> flag
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We can update the signature of
>>>>> isNonEmpty()
>>>>>>>> to
>>>>>>>>>>>>>>> remove
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> boolean
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> parameter.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun Rao <j...@confluent.io.INVALID> 於
>>>>>>>>>> 2025年5月1日
>>>>>>>>>>>>>>>>> 凌晨4:17
>>>>>>>>>>>>>>>>>>>>>>>>> 寫道：
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do we really need isEmptyAllowed?
>> It's
>>>>>>>>>> awkward
>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>> method
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> name
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inNonEmpty. Also, it's not clear when
>>>>> it's
>>>>>>>>>> set
>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> true.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Apr 25, 2025 at 6:26 AM 黃竣陽 <
>>>>>>>>>>>>>>>>>>>>>>>> s7133...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Jun,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you for pointing that out.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have revised the KIP as follows:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> “In this case, the change does not
>>>>>>>> introduce
>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>>>>>>> invalid
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prevent any currently valid setup.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The main behavioral difference is
>> that
>>>>> we
>>>>>>>>>> now
>>>>>>>>>>>>>>>>>>>>>>>> explicitly
>>>>>>>>>>>>>>>>>>>>>>>>>>>> throw a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ConfigException during the storage
>>>>>>> format
>>>>>>>>>>>>>>>>> validation
>>>>>>>>>>>>>>>>>>>>>>>>> phase
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instead of relying on the current
>>>>>>>> behavior.”
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This reflects the correct behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun Rao <j...@confluent.io.INVALID>
>> 於
>>>>>>>>>>>>>> 2025年4月25日
>>>>>>>>>>>>>>>>>>>>>>>>> 凌晨1:17 寫道：
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "The main behavioral difference
>>>>>>> introduced
>>>>>>>>>> by
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>>> change
>>>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ConfigException will now be thrown
>>>>>>> during
>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>> storage
>>>>>>>>>>>>>>>>>>>>>>>>>>> format
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> phase, rather than during server
>>>>>>> startup."
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It seems that currently formating
>> the
>>>>>>>>>> storage
>>>>>>>>>>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>>>>>>>>>>>> fails
>>>>>>>>>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> group.coordinator.rebalance.protocols
>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>> process.roles
>>>>>>>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> empty.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> gets a different exception.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Apr 24, 2025 at 5:32 AM
>> 黃竣陽 <
>>>>>>>>>>>>>>>>>>>>>>>>> s7133...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Jun, chia,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for your feedback.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I add a new section for this
>> change:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - Validation for
>>>>>>>>>>>>>>>>>>>>>>>>> group.coordinator.rebalance.protocols and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> process.roles
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> moved from the server startup
>> phase
>>> to
>>>>>>>> the
>>>>>>>>>>>>>>>>> storage
>>>>>>>>>>>>>>>>>>>>>>>>> format
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> phase.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - For cleanup.policy, setting an
>>> empty
>>>>>>>>>> list
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>> now
>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> considered
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> result in a ConfigException during
>>>>>>>> storage
>>>>>>>>>>>>>>> format
>>>>>>>>>>>>>>>>>>>>>>>>> phase.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun Rao <j...@confluent.io.INVALID
>>>
>>> 於
>>>>>>>>>>>>>>> 2025年4月24日
>>>>>>>>>>>>>>>>>>>>>>>>> 凌晨4:44
>>>>>>>>>>>>>>>>>>>>>>>>>>> 寫道：
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Q2. It's true that
>>>>>>>>>>>>>>>>>>>>>>>>> group.coordinator.rebalance.protocols
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> process.roles
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configurations can't be empty
>> right
>>>>>>> now.
>>>>>>>>>>> With
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>>> KIP,
>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> probably get a different (and
>> more
>>>>>>>>>>> accurate)
>>>>>>>>>>>>>>>>>>>>>>>>> exception.
>>>>>>>>>>>>>>>>>>>>>>>>>>> It
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> useful
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to document that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regarding cleanup.policy, I kind
>> of
>>>>>>>> agree
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>> Chia-Ping.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> leaves
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy empty, it's more
>>>>> likely
>>>>>>>> to
>>>>>>>>>>> be
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>>>>>>> mistake
>>>>>>>>>>>>>>>>>>>>>>>>>>> than
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> intention.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If we automatically treat it as
>>> None,
>>>>>>>> the
>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>>>>>>> never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> realize
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mistake. Throwing an exception
>> will
>>>>>>> let
>>>>>>>>>> the
>>>>>>>>>>>>>>> user
>>>>>>>>>>>>>>>>>>>>>>>>> realize
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Apr 23, 2025 at 8:26 AM
>>>>>>>> Chia-Ping
>>>>>>>>>>>>>> Tsai
>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> chia7...@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hi Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the KIP, and I
>>> understand
>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>>>>>>>> maintaining
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compatibility
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> important.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> However, according to the
>>>>>>>> documentation,
>>>>>>>>>>> we
>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>>>>>>>>> allow
>>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> value
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the cleanup.policy. Hence,
>> should
>>> we
>>>>>>>>>>>>>> consider
>>>>>>>>>>>>>>>>>>>>>>>>> throwing
>>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> exception
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> empty value in version 4.x? This
>>>>>>> could
>>>>>>>>>>>>>>>>> streamline
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> avoid
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> extra deprecation cycle.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Chia-Ping
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun Rao
>> <j...@confluent.io.invalid
>>>>
>>>>> 於
>>>>>>>>>>>>>>>>> 2025年4月23日
>>>>>>>>>>>>>>>>>>>>>>>> 週三
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 上午6:33寫道：
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Regarding "The none policy will
>>> not
>>>>>>>>>>> delete
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>>> compact
>>>>>>>>>>>>>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> segments",
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should be more accurate. We
>> won't
>>>>>>>>>> delete
>>>>>>>>>>>>>>>>>>>>>>>> segments
>>>>>>>>>>>>>>>>>>>>>>>>> based
>>>>>>>>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> log.retention.bytes/
>>>>>>> log.retention.ms,
>>>>>>>>>>> but
>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> continue
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> delete
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> segments based on
>>>>>>>>>>>>>> log.local.retention.bytes/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> log.retention.ms.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Otherwise,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> risk running out of local disk
>>>>> space
>>>>>>>>>> when
>>>>>>>>>>>>>>>>> remote
>>>>>>>>>>>>>>>>>>>>>>>>>>> storage
>>>>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> enabled.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 22, 2025 at 9:45 AM
>>> Jun
>>>>>>>>>> Rao <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> j...@confluent.io>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Q2. What about existing empty
>>>>>>> values
>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> group.coordinator.rebalance.protocols
>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>>> process.roles
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> during
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> upgrade?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 22, 2025 at
>> 7:29 AM
>>>>>>> 黃竣陽 <
>>>>>>>>>>>>>>>>>>>>>>>>>>> s7133...@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hello Jun,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for review this KIP.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Q1 & Q3:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I’ve updated the method name
>>>>>>>>>>> accordingly
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> revised
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> documentation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to clarify that the none
>> policy
>>>>>>>>>> cannot
>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> used
>>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> policy.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Q2:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For users currently using an
>>>>> empty
>>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy,
>>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> apply the none policy
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> during the
>>> preProcessParsedConfig
>>>>>>>>>> step.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Additionally, a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> warning
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> message
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will be emitted to inform
>> users
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the upcoming change.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun Rao
>>>>> <j...@confluent.io.INVALID
>>>>>>>>
>>>>>>>>>> 於
>>>>>>>>>>>>>>>>>>>>>>>> 2025年4月22日
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 凌晨4:52
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 寫道：
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the KIP. A few
>>>>>>> comments.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. It's fine to introduce a
>>> new
>>>>>>>>>> value
>>>>>>>>>>>>>> None
>>>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> now
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> all value combinations are
>>>>> valid.
>>>>>>>>>> For
>>>>>>>>>>>>>>>>>>>>>>>> example,
>>>>>>>>>>>>>>>>>>>>>>>>> None
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Delete or Compact. It would
>> be
>>>>>>>>>> useful
>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>>> document
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. What's the behavior
>> during
>>>>>>>>>> upgrade
>>>>>>>>>>>>>> when
>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>> existing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> config
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> list.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3. inWithEmptyCheck: It's
>> not
>>>>>>> clear
>>>>>>>>>>> what
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>>>>>>>>>>>>> check
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sth like inNonEmpty ?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tue, Apr 15, 2025 at
>>> 8:25 AM
>>>>>>> 黃竣陽
>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> s7133...@gmail.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hello everyone,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would like to start a
>>>>>>> discussion
>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>>>>> KIP-1161:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> shouldn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be empty
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/x/HArXF>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This proposal aims to
>> improve
>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> configuration.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Currently,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this setting should not be
>>> left
>>>>>>>>>>> empty.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Therefore, there are two
>>>>>>> proposed
>>>>>>>>>>>>>>>>>>>>>>>> improvements:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Update ValidList to
>>> validate
>>>>>>>>>>> whether
>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>>>>>>>>>>>> list
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> allowed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. Introduce a new 'none'
>>> value
>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>>>>> cleanup.policy.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
