Thank you, Ismael. Sent from my iPhone
> On Jan 6, 2017, at 4:46 PM, Ismael Juma <ism...@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.hoo...@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 <ism...@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.hoo...@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 <ism...@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 <cmcc...@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 <ism...@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" <rajinisiva...@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 <ism...@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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>
