[jira] [Commented] (KAFKA-21094) consolidate config generation in createTopics and describeConfigs

["Jun Rao (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-21094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18115262#comment-18115262 ] 

Jun Rao commented on KAFKA-21094:
---------------------------------

Claude suggested the two following approaches.
{code:java}
Two ways to sequence it:

Full unification (best): move the topic DescribeConfigs path onto KafkaConfigSchema.resolveEffectiveTopicConfigs, decorating the ConfigEntrys for the response. Scope to topics, gate behind thorough parity tests (source, values, included keys, synonyms).

Cheap first step (low risk): extract just the inclusion rule — "non-internal always; internal/unknown only if explicitly set" — into one shared helper both sides call, so they can't silently drift even before the value-resolution is unified. {code}

> consolidate config generation in createTopics and describeConfigs
> -----------------------------------------------------------------
>
>                 Key: KAFKA-21094
>                 URL: https://issues.apache.org/jira/browse/KAFKA-21094
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Jun Rao
>            Priority: Major
>
> CreateTopics has the following path to generate the configs in the response.
> {code:java}
> controller/metadata sideReplicationControlManager.createTopic  → computeEffectiveTopicConfigs(creationConfigs)      // ReplicationControlManager.java:841      → ConfigurationControlManager.computeEffectiveTopicConfigs(creationConfigs)   // :802          → KafkaConfigSchema.resolveEffectiveTopicConfigs(                          // KafkaConfigSchema.java:150  ← the call                staticConfig, clusterConfig(), nodeConfig, dynamicTopicConfigs)  → build CreateTopicsResponseData.CreatableTopicConfigs   // ReplicationControlManager.java:846The call: KafkaConfigSchema.resolveEffectiveTopicConfigs(...) → returns Map<String, ConfigEntry>. {code}
>  
> DescribeConfigs (topic) has a different path to generate the configs in its response.
> {code:java}
> broker sideConfigHelper.describeConfigs                              // ConfigHelper.scala:82  topicProps = configRepository.topicConfig(topic)        // the topic's overrides  logConfig  = LogConfig.fromProps(config.extractLogConfigMap, topicProps)   // :93  (broker log defaults ⊕ topic overrides)  → ConfigHelperUtils.createResponseConfig(               // :95  ← the call        resource, logConfig, logConfig.overriddenConfigs, createTopicConfigEntry(...))The call: ConfigHelperUtils.createResponseConfig(resource, logConfig, explicitlySetConfigs, …). {code}
> It would be useful to look into if it's possible to consolidate them into a single shared path to avoid divergence in the future.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)