[
https://issues.apache.org/jira/browse/KAFKA-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Hauch reassigned KAFKA-13028:
-------------------------------------
Assignee: Randall Hauch
> AbstractConfig should allow config provider configuration to use variables
> referencing other config providers earlier in the list
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-13028
> URL: https://issues.apache.org/jira/browse/KAFKA-13028
> Project: Kafka
> Issue Type: Improvement
> Components: clients, KafkaConnect
> Reporter: Randall Hauch
> Assignee: Randall Hauch
> Priority: Major
>
> When AbstractConfig recognizes config provider properties, it instantiates
> all of the config providers first and then uses those config providers to
> resolve any variables in remaining configurations. This means that if you
> define two config providers with:
> {code}
> config.providers=providerA,providerB
> ...
> {code}
> then the configuration properties for the second provider (e.g., `providerB`)
> cannot use variables that reference the first provider (e.g., `providerA`).
> In other words, this is not possible:
> {code}
> config.providers=providerA,providerB
> config.providers.providerA.class=FileConfigProvider
> config.providers.providerB.class=ComplexConfigProvider
> config.providers.providerA.param.client.key=${file:/usr/secrets:complex.client.key}
> config.providers.providerA.param.client.secret=${file:/usr/secrets:complex.client.secret}
> {code}
> This should be possible if the config providers are instantiated and
> configured in the same order as they appear in the `config.providers`
> property. The benefit is that it allows another level of indirection so that
> any secrets required by config provider can be resolved using an earlier
> simple config provider.
> For example, config providers are often defined in Connect worker
> configurations to resolve secrets within connector configurations, or to
> resolve secrets within the worker configuration itself (e.g., producer or
> consumer secrets). But it would be useful to also be able to resolve the
> secrets needed by one configuration provider using another configuration
> provider that is defined earlier in the list.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
