Thank you, Ismael.
Sent from my iPhone
> On Jan 6, 2017, at 4:46 PM, Ismael Juma wrote:
>
> Thanks Roger. I asked around and it seems like `listener name` is what
> people found most intuitive in the context of configs. So, I have updated
> the KIP to use that.
>
> Ismael
>
>> On Fri, Jan 6,
Thanks Roger. I asked around and it seems like `listener name` is what
people found most intuitive in the context of configs. So, I have updated
the KIP to use that.
Ismael
On Fri, Jan 6, 2017 at 9:42 PM, Roger Hoover wrote:
> Ismael,
>
> Listener id would also convey uniqueness but I'm ok with
Ismael,
Listener id would also convey uniqueness but I'm ok with listener key as well
since it fits with the use of the term "map" in other properties.
My initially feeling against the word key was that it seemed more natural in
documentation about Kafka allowing multiple listener (even with
Hi Roger,
I think `listener_key` makes it clear that it has to be unique per
listener, so I prefer it a little over `listener_name`. Since the existing
config is called `listeners` instead of `protocol.listeners`, maybe we
don't need the protocol prefix?
Ismael
On Fri, Jan 6, 2017 at 7:48 PM, Ro
Maybe it's clearer to to say protocol_listener_name? The proposed config
allows you to name each listener and refer to their names in various places.
On Wed, Jan 4, 2017 at 4:34 AM, Ismael Juma wrote:
> Hi Colin,
>
> Thanks for the feedback. It's a good question regarding the name `protocol
>
I updated the KIP to cover point 1 as well.
If there are no additional comments, I intend to start a vote thread within
a day or two.
Thanks,
Ismael
On Wed, Jan 4, 2017 at 11:30 PM, Ismael Juma wrote:
> Thanks for the review Jun. Replies follow.
>
> 1. That's a very good point. Adding a prefix
Thanks for the review Jun. Replies follow.
1. That's a very good point. Adding a prefix to the JAAS entry name with a
fallback to the name without the prefix is consistent with how the other
configs are handled, so I'll update the KIP to mention that.
2. That was a typo, thanks for catching it. I
Hi, Ismael,
Thanks for the proposal. Looks good to me overall. Just a couple of minor
comments.
1. Sasl also has some properties provided through the login context in the
jaas file. Do we want to extend that to allow different login context for
different protocol labels on the server side (e.g. L
Hi Colin,
Thanks for the feedback. It's a good question regarding the name `protocol
label`. It was an easy starting name given that the security protocol was
replaced by a label in the listener string. However, I agree that it's
perhaps not as clear as it could be. Maybe `listener key` would be a
Good idea. It would be really nice to be able to constrain replication
traffic to a specific interface or use different security settings.
I'm having a little trouble understanding the "protocol label" concept.
Clearly protocol labels map to protocols, but they also seem to identify
particular t
I've updated the KIP to:
1. Include the ability to set different security configs depending on the
protocol label.
2. Include the mapping from protocol label to security protocol in ZK and
UpdateMetadataRequest.
3. More items in the "Rejected Alternatives" section.
4. Take into account old ZooKeep
Thanks Rajini.
I agree that it's worth thinking about what a fully configurable label
would look like. I'll update the KIP.
Ismael
On 21 Dec 2016 10:53 pm, "Rajini Sivaram" wrote:
Hi Ismael,
Thank you for the KIP. This is a very useful change.
Once you allow multiple interfaces with the same
Hi Ismael,
Thank you for the KIP. This is a very useful change.
Once you allow multiple interfaces with the same security protocol, you
will soon also need to be able to configure protocol-specific properties
for each of the interfaces. To use SSL on internal and external networks,
you would almo
13 matches
Mail list logo
