[ 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)