[
https://issues.apache.org/jira/browse/KAFKA-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shikhar Bhushan updated KAFKA-3962:
-----------------------------------
Description:
It often comes up with connectors that you want some piece of configuration
that should be overridable at the topic-level, table-level, etc.
The ConfigDef API should allow for defining these resource-overridable config
properties and we should have getter variants that accept a resource argument,
and return the more specific config value (falling back to the default).
There are a couple of possible ways to allow for this:
1. Support for map-style config properties "resource1:v1,resource2:v2". There
are escaping considerations to think through here. Also, how should the user
override fallback/default values -- perhaps {{*}} as a special resource?
2. Templatized configs -- so you would define {{$resource.some.property}}. The
default value is more naturally overridable here, by the user setting
{{some.property}} without the {{$resource}} prefix.
was:
It often comes up with connectors that you want some piece of configuration
that should be overridable at the topic-level, table-level, etc.
There are a couple of possible ways to allow for this:
1. Support for map-style config properties "k1:v1,k2:v2". There are escaping
considerations to think through here. Also, how should the user override
fallback/default values -- perhaps {{*}} as a special resource?
2. Templatized configs -- so we can define {{$resource.some.property}} with the
ConfigDef API, and have getter variants that take the resource argument. The
default value is more naturally overridable here, by the user setting
{{some.property}}.
> ConfigDef support for resource-specific configuration
> -----------------------------------------------------
>
> Key: KAFKA-3962
> URL: https://issues.apache.org/jira/browse/KAFKA-3962
> Project: Kafka
> Issue Type: Improvement
> Reporter: Shikhar Bhushan
>
> It often comes up with connectors that you want some piece of configuration
> that should be overridable at the topic-level, table-level, etc.
> The ConfigDef API should allow for defining these resource-overridable config
> properties and we should have getter variants that accept a resource
> argument, and return the more specific config value (falling back to the
> default).
> There are a couple of possible ways to allow for this:
> 1. Support for map-style config properties "resource1:v1,resource2:v2". There
> are escaping considerations to think through here. Also, how should the user
> override fallback/default values -- perhaps {{*}} as a special resource?
> 2. Templatized configs -- so you would define {{$resource.some.property}}.
> The default value is more naturally overridable here, by the user setting
> {{some.property}} without the {{$resource}} prefix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
