Hi Ying, I was also thinking about your KIP yesterday I second Gwen on this. There are several other authorization components that are compatible with Kafka and putting this in there means that each and every component has to implement this functionality. At the first read I thought that this functionality could be a good extension of the API_VERSIONS protocol where based on a dynamic config (producer.min.api.version or consumer.min.api.version) the brokers would reject certain clients that are too old. And based on the motivation, to avoid certain bugs with certain producer/consumer version, we might not need finer grained control over this which I think also plays for the config approach.
Cheers, Viktor On Sat, Feb 23, 2019 at 12:06 AM Ying Zheng <yi...@uber.com.invalid> wrote: > Hi Gwen, > > Thank you for the quick feedback! > > It's a good point that broker configuration can be dynamic and is more > convenient. Technically, anything inside the authorizer can also be > dynamic. For example, the SimpleAclAuthorizer in Kafka stores ACLs in > Zookeeper, which can be dynamically changed with CLI. > > > > > > On Fri, Feb 22, 2019 at 2:41 PM Gwen Shapira <g...@confluent.io> wrote: > > > Link, for convenience: > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-433%3A+Provide+client+API+version+to+authorizer > > > > I actually prefer the first rejected alternative (add a > > configuration). While you are right that configuration is inherently > > less flexible, putting the logic in the authorizer means that an admin > > that wants to limit the allowed client API versions has to implement > > an authorizer. This is more challenging than changing a config (and > > AFAIK, can't be done dynamically - configs can be dynamic and the > > admin can avoid a restart). > > > > Would be interested to hear what others think. > > > > Gwen > > > > On Fri, Feb 22, 2019 at 2:11 PM Ying Zheng <yi...@uber.com.invalid> > wrote: > > > > > > > > > > > > -- > > Gwen Shapira > > Product Manager | Confluent > > 650.450.2760 | @gwenshap > > Follow us: Twitter | blog > > >
