kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pellerin, Clement" <Clement_Pelle...@ibi.com>
Subject RE: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible
Date Wed, 11 Sep 2019 04:06:46 GMT
Regarding what I labeled the simplest solution below, SslConfigs could instantiate the custom
interface only if the yet to be validated configs were passed in to the call to get the list
of known SSL configs.

-----Original Message-----
From: Pellerin, Clement 
Sent: Tuesday, September 10, 2019 11:36 AM
To: dev@kafka.apache.org
Subject: [EXTERNAL]RE: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible

Another solution could be a new standard ssl config that holds a list of extra custom configs
to accept.
Using a custom SslEngineFactory with custom configs would require setting two configs, one
for the class name and another for the list of custom configs.
In SslConfigs, we see that declaring a single config takes 5 values, so I'm not sure how it
would work exactly.

We could also declare a new interface to return the list of custom ssl configs and the extra
standard ssl config I'm proposing holds the name of the implementation class instead. The
reason a different interface is needed is because it would be instantiated by SslConfigs,
not SslFactory.
This seems the simplest solution.

Anyway, the point of this exercise is to prove an acceptable solution for custom configs is
not affecting the public API in KIP-519.


-----Original Message-----
From: Pellerin, Clement 
Sent: Tuesday, September 10, 2019 9:35 AM
To: dev@kafka.apache.org
Subject: [EXTERNAL]RE: [DISCUSS] KIP-519: Make SSL context/engine configuration extensible

Custom config is a term I invented to mean a config that does not exist in Kafka but is specified
by a custom implementation of SslEngineFactory.
The problem with custom configs (as I remember it) is that the list of configs is static in
SslConfigs and config names are checked before SslFactory is created.
==> You must solve this problem because that is what killed KIP-383 and therefore is the
sole reason why KIP-519 exists.
==> Your KIP does not have to implement the solution since it can be done in a future KIP,
but your KIP must be compatible with the solution found.
==> A method to return the list of configs would help. This cannot be a static method in
the interface since it cannot be overridden.
==> You could require a static method in the implementation class by convention, just like
the constructor you require.

This email did not originate from inside Information Builders.
Mime
View raw message