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