Hello Jun, Thanks for the reply.
JR33, I’ve updated the validator to only allow non-empty lists. However, I have a question about the default value: It seems that in Streams, the config uses NO_DEFAULT_VALUE and includes a comment saying “required with no default value.” Should we also consider changing the default from NO_DEFAULT_VALUE to List.of()? JR34: For these two configurations, setting an empty list feels a bit unintuitive. If an empty list is provided, the consumer will call the unsubscribe method, which doesn't seem appropriate given the documentation states: "Topic-partitions assigned to this task to replicate." JR35: AsyncConsumer doesn’t support this config, I updated it. JR36: For ssl.enabled.protocols, the value is only accessed in DefaultSslEngineFactory[1], where null and an empty list result in the same behavior. Since users cannot set a null value through a configuration file, I believe we can safely disallow null values and allow empty lists instead. [1]https://github.com/apache/kafka/blob/9572d19c5911f401a155741fcce61b69657aae79/clients/src/main/java/org/apache/kafka/common/security/ssl/DefaultSslEngineFactory.java#L146 Best Regards, Jiunn-Yang > Jun Rao <j...@confluent.io.INVALID> 於 2025年7月18日 清晨6:32 寫道： > > Hi, Jiunn-Yang, > > Thanks for the reply. > > JR31. This is fine then. > > JR33. StreamsConfig: bootstrap.servers can't be empty. > bootstrap.controllers is not available in Streams. It's only available in > AdminClient. > > JR34. If there are more MM instances than partitions, it seems that it's > possible for task.assigned.partitions to be empty. > Ditto for task.assigned.groups. > > JR35. partition.assignment.strategy: It's only needed if group.protocol is > classic. I guess that it's ok for it to be empty. > > JR36. ssl.enabled.protocols: This is interesting. If this is null, it > implies that all available protocols are enabled. However, since null is > not the default value, a user can't set it to null through a config file. I > am wondering if this is ever needed. > > Jun > > On Thu, Jul 17, 2025 at 7:23 AM 黃竣陽 <s7133...@gmail.com> wrote: > >> 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >> >>
