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