Thanks, Robert.  Looks good overall.

As a clarification about the indirections, what if I have the connect 
configuration key foo set up as ${vault:bar}, and in Vault, have the bar key 
set to ${file:baz}?  Does connect get foo as the contents of the baz file?  I 
would argue that it should not (and in general, we shouldn't allow 
ConfigProviders to indirect to other ConfigProviders) but I don't think it's 
spelled out right now.

What's the behavior when a config key is not found in Vault (or other 
ConfigProvider)?  Does the variable get replaced with the empty string, or with 
the literal ${vault:whatever} string?

Do we really need "${provider:[path:]key}", or can it just be ${provider:key}?  
It seems like the path can be rolled up into the key.  So if you want to put 
your connect keys under my.connect.path, you ask for 
${vault:my.connect.path.jdbc.config}, etc.

>    // A delayMs of 0 indicates an immediate change; a positive delayMs 
> indicates 
>    // that a future change is anticipated (such as a lease duration)
>    void onChange(String path, Map<String, String> values, int delayMs);

Do we really need delayMs?  It seems like if you get a callback with delayMs 
set, you don't know what the new values will be, only that an update is coming, 
but not yet here.

best,
Colin


On Wed, May 16, 2018, at 17:05, Robert Yokota wrote:
> Hello everyone,
> 
> After a good round of discussions with excellent feedback and no major
> objections, I would like to start a vote on KIP-297 to externalize secrets
> from Kafka Connect configurations.  My thanks in advance!
> 
> KIP: <
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-297%3A+Externalizing+Secrets+for+Connect+Configurations
> >
> 
> JIRA: <https://issues.apache.org/jira/browse/KAFKA-6886>
> 
> Discussion thread: <
> https://www.mail-archive.com/dev@kafka.apache.org/msg87638.html>
> 
> Best,
> Robert

Reply via email to