Randall Hauch created KAFKA-13028:
-------------------------------------
Summary: 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
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)
