You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Shikhar Bhushan (JIRA)" <ji...@apache.org> on 2016/07/13 23:03:20 UTC
[jira] [Updated] (KAFKA-3962) ConfigDef support for
resource-specific configuration
[ 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)