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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>> >>
