kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Hoover <roger.hoo...@gmail.com>
Subject Re: KIP-103: Separation of Internal and External traffic
Date Sat, 07 Jan 2017 03:18:11 GMT
Thank you, Ismael.

Sent from my iPhone

> On Jan 6, 2017, at 4:46 PM, Ismael Juma <ismael@juma.me.uk> 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, 2017 at 9:42 PM, Roger Hoover <roger.hoover@gmail.com> wrote:
>> 
>> 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 the
>> same protocol) and listeners are identified by name or ID.  It seemed a
>> little more awkward to talk about listeners having keys as identifiers.
>> That fact that the listener ID is used as a key in config maps is secondary.
>> 
>> Your suggestion for removing the protocol prefix makes sense.  Listeners
>> must have a protocol but that ZooKeeper field is only meant to hold the
>> listener ID.
>> 
>> Cheers,
>> 
>> Roger
>> 
>> Sent from my iPhone
>> 
>>> On Jan 6, 2017, at 12:24 PM, Ismael Juma <ismael@juma.me.uk> wrote:
>>> 
>>> 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, Roger Hoover <roger.hoover@gmail.com>
>> wrote:
>>>> 
>>>> 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 <ismael@juma.me.uk>
wrote:
>>>>> 
>>>>> 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
>>>> better
>>>>> name? It makes it clear that it should be unique in a listeners list
>> and
>>>>> that it's used to associate a listener to something else (like a
>> security
>>>>> protocol). Thoughts?
>>>>> 
>>>>> Ismael
>>>>> 
>>>>> On Wed, Jan 4, 2017 at 12:29 AM, Colin McCabe <cmccabe@apache.org>
>>>> wrote:
>>>>> 
>>>>>> 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 types of traffic.  Would it be more appropriate to call
>>>> these
>>>>>> "traffic types" or "endpoint types"?  Or am I misunderstanding the
>>>>>> proposal?
>>>>>> 
>>>>>> cheers,
>>>>>> Colin
>>>>>> 
>>>>>> 
>>>>>>> On Thu, Dec 22, 2016, at 08:00, Ismael Juma wrote:
>>>>>>> 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 ZooKeeper-based consumers.
>>>>>>> 
>>>>>>> Feedback is appreciated as always.
>>>>>>> 
>>>>>>> I'm particularly interested in people's opinions on the config
format
>>>>> as
>>>>>>> I
>>>>>>> am still unsure when it comes to the proposed format versus the
first
>>>>>>> rejected alternative.
>>>>>>> 
>>>>>>> Ismael
>>>>>>> 
>>>>>>> On Wed, Dec 21, 2016 at 11:37 PM, Ismael Juma <ismael@juma.me.uk>
>>>>> wrote:
>>>>>>> 
>>>>>>>> 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" <rajinisivaram@gmail.com
>>>>> 
>>>>>> wrote:
>>>>>>>> 
>>>>>>>> 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 almost definitely want different keystores with
different
>>>>>>>> hostname/IP addresses. Similarly for SASL, you might want
to enable
>>>>>>>> different mechanisms, use a different authentication server
etc.
>>>> This
>>>>>> is
>>>>>>>> listed under future work.But it may be worth thinking about
what a
>>>>>> fully
>>>>>>>> configurable 'label' looks like. Would every property now
become a
>>>>>> list/map
>>>>>>>> like listeners - you would then end up with maps of lists
for some
>>>>>>>> properties. It will good if all properties corresponding
to a
>>>> label
>>>>>>>> including listener and advertised.listener are configured
>>>>> consistently
>>>>>> - if
>>>>>>>> that is possible,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Wed, Dec 21, 2016 at 8:56 PM, Ismael Juma <ismael@juma.me.uk>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hi all,
>>>>>>>>> 
>>>>>>>>> We've posted "KIP-103: Separation of Internal and External
>>>> traffic"
>>>>>> for
>>>>>>>>> discussion:
>>>>>>>>> 
>>>>>>>>> *https://cwiki.apache.org/confluence/display/KAFKA/KIP-
>>>>>>>>> 103%3A+Separation+of+Internal+and+External+traffic
>>>>>>>>> <https://cwiki.apache.org/confluence/display/KAFKA/KIP-
>>>>>>>>> 103%3A+Separation+of+Internal+and+External+traffic>*
>>>>>>>>> 
>>>>>>>>> Please take a look. Your feedback is appreciated.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Ismael
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 

Mime
View raw message