Hi, Ismael, Thanks for the proposal. Looks good to me overall. Just a couple of minor comments.
1. Sasl also has some properties provided through the login context in the jaas file. Do we want to extend that to allow different login context for different protocol labels on the server side (e.g. Label1KafkaServer, Label2KafkaServer)? This doesn't have to be implemented right away though, as long as we have a plan on how to extend it in the future. 2. In the UpdateMetadataRequest protocol, could you describe what's in listener_security_protocol_map? Also, since we include protocol_label in endpoints, do we really need to include listener_security_protocol_map? Jun 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 > > > > > > > > > > > > > > > > > > > >
