Hey Guys, If there are no objections or major modifications to suggest I would like to start a vote thread on this. I will wait till EOD today before starting a vote thread.
On Thu, Apr 21, 2016 at 4:36 PM, Gwen Shapira <g...@confluent.io> wrote: > I would like to suggest taking the discussion of "how to break Kafka > down into modules" outside the scope of KIP-50 and outside the scope > of the next release. > > I understand that the current location of the authorizer API is not > ideal, but I want to point out that the scope was already expanded > from a new method to a complete rewrite of the authorizer. Is the > current location really bad enough to expand the scope into larger > refactoring of Kafka? > > Gwen > > On Wed, Apr 20, 2016 at 10:43 PM, Ismael Juma <ism...@juma.me.uk> wrote: > > Hi Jay, > > > > Thanks for summarising the reasoning for the current approach. On the > topic > > of additional jars, the obvious example that came up recently is sharing > > JSON serializers between connect and streams. Given the desire not to > add a > > Jackson dependency to clients, it seems like adding a > kafka-serializer-json > > (or something like that) may be needed. This is similar to the > > kafka-log4j-appender jar that we have today. > > > > When you look at it this way, then the situation is not as clear-cut as > > initially described. Perhaps a way to explain this is that we only add > > additional modules when they introduce a new dependency. > > > > Finally, it seems a bit weird to add something to `common` that is, in > > fact, not common. Would it not make sense to have a separate package for > > pluggable core/server classes (because they are pluggable we want them to > > be in Java and not to be associated with a particular Scala version)? > > > > Ismael > > > > On Wed, Apr 20, 2016 at 4:52 PM, Jay Kreps <j...@confluent.io> wrote: > > > >> Yeah our take when we came up with this approach was pretty much what > Gwen > >> is saying: > >> 1. In practice you either need the server or client to do anything and > the > >> server depends on the client so bundling common and client doesn't hurt. > >> 2. Our experience with more granular jars (not in Kafka) was that > although > >> it feels "cleaner" the complexity comes quickly for a few reasons. > First it > >> gets hard to detangle the more granular packages (e.g. somebody needs to > >> use something in Utils in the authorizer package and then you no longer > >> have a dag). Second people end up mixing and matching in ways you didn't > >> anticipate which causes crazy heisenbugs (e.g. they depend on two > different > >> versions of the client via transitive dependencies and somehow end up > with > >> client version x and common version y due to duplicate entries on the > class > >> path). > >> > >> I'm not really arguing that this approach is superior, I'm just saying > this > >> is the current approach and that is the reason we went with it. > >> > >> So I could see splitting common and client and you could even further > split > >> the producer and consumer and multiple sub-jars in common, and if this > was > >> the approach I think a separate authorizer jar would make sense. But in > the > >> current approach I think the authorizer stuff would be most consistent > as a > >> public package in common. It is true that this means you build against > more > >> stuff then needed but I'm not sure this has any negative implications in > >> practice. > >> > >> -Jay > >> > >> On Wed, Apr 20, 2016 at 4:17 PM, Gwen Shapira <g...@confluent.io> > wrote: > >> > >> > But its just a compile-time dependency, right? > >> > Since the third-party-authorizer-implementation will be installed on a > >> > broker where the common classes will exist anyway. > >> > > >> > > >> > On Wed, Apr 20, 2016 at 3:13 PM, Ashish Singh <asi...@cloudera.com> > >> wrote: > >> > > Jay, > >> > > > >> > > Thanks for the info. I think having common in clients jar makes > sense, > >> as > >> > > their is no direct usage of it. i.e., without depending on or using > >> > > clients. Authorizer is a bit different, as third party > implementations > >> do > >> > > not really need anything from clients or server, all they need is > >> > > Authorizer interface and related classes. If we move authorizer into > >> > > common, then third party implementations will have to depend on > >> clients. > >> > > Though third party implementations depending on clients is not a big > >> > > problem, right now they depend on core, I think it is cleaner to > have > >> > > dependency on minimal modules. Would you agree? > >> > > > >> > > On Wed, Apr 20, 2016 at 2:27 PM, Jay Kreps <j...@confluent.io> > wrote: > >> > > > >> > >> I think it's great that we're moving the interface to java and > fixing > >> > some > >> > >> of the naming foibles. > >> > >> > >> > >> This isn't explicit in the KIP which just refers to the java > package > >> > name > >> > >> (I think), but it looks like you are proposing adding a new > authorizer > >> > jar > >> > >> for this new package and adding it as a dependency for the client > jar. > >> > This > >> > >> is a bit inconsistent with how we decided to package stuff when we > >> > started > >> > >> with the new clients so it'd be good to work that out. > >> > >> > >> > >> To date the categorization has been: > >> > >> 1. Anything which is just in the clients is in org.apache.clients > >> under > >> > >> clients/ > >> > >> 2. Anything which is in the server is kafka.* which is under core/ > >> > >> 3. Anything which is needed in both places (as it sounds like some > >> enums > >> > >> for authorization are?) is in common which is under clients/ > >> > >> > >> > >> org.apache.clients and org.apache.common are both pure java and > >> > dependency > >> > >> free other than the compression libraries and slf4j and are > packaged > >> > into > >> > >> the kafka-clients.java, the server has it's own jar which has > richer > >> > >> dependencies and depends on the client jar. > >> > >> > >> > >> There are other ways this could have been done--e.g. common could > have > >> > been > >> > >> its own library or even split into multiple sub-libraries--but the > >> > decision > >> > >> at that time was just to keep it simple and hard to mess up. Based > on > >> > the > >> > >> experience with the scala clients our plan was to be ultra-hostile > to > >> > any > >> > >> added client dependencies. > >> > >> > >> > >> So I think if we're continuing this model we would put the shared > >> > >> authorizer code somewhere under > >> > >> clients/src/main/java/org/apache/kafka/common as with the other > shared > >> > >> authorizer. If we're moving away from this model we should probably > >> > rethink > >> > >> things and be consistent with this, at the very least splitting up > >> > common > >> > >> and clients. > >> > >> > >> > >> -Jay > >> > >> > >> > >> On Wed, Apr 20, 2016 at 1:04 PM, Ashish Singh <asi...@cloudera.com > > > >> > wrote: > >> > >> > >> > >> > Jun/ Jay/ Gwen/ Harsha/ Ismael, > >> > >> > > >> > >> > As you guys have provided feedback on this earlier, could you > review > >> > the > >> > >> > KIP again? I have updated the PR < > >> > >> https://github.com/apache/kafka/pull/861> > >> > >> > as > >> > >> > well. > >> > >> > > >> > >> > On Wed, Apr 20, 2016 at 1:01 PM, Ashish Singh < > asi...@cloudera.com> > >> > >> wrote: > >> > >> > > >> > >> > > Hi Grant, > >> > >> > > > >> > >> > > On Tue, Apr 19, 2016 at 8:13 AM, Grant Henke < > ghe...@cloudera.com > >> > > >> > >> > wrote: > >> > >> > > > >> > >> > >> Hi Ashish, > >> > >> > >> > >> > >> > >> Thanks for the updates. I have a few questions below: > >> > >> > >> > >> > >> > >> > Move following interfaces to new package, > >> > >> org.apche.kafka.authorizer. > >> > >> > >> > > >> > >> > >> > 1. Authorizer > >> > >> > >> > 2. Acl > >> > >> > >> > 3. Operation > >> > >> > >> > 4. PermissionType > >> > >> > >> > 5. Resource > >> > >> > >> > 6. ResourceType > >> > >> > >> > 7. KafkaPrincipal > >> > >> > >> > 8. Session > >> > >> > >> > > >> > >> > >> > > >> > >> > >> This means the client would be required to depend on the > >> authorizer > >> > >> > >> package > >> > >> > >> as a part of KIP-4. Another option is to have the client > objects > >> in > >> > >> > >> common. > >> > >> > >> Have we ruled out leaving the interface in the core module? > >> > >> > >> > >> > >> > > With this entities that use Authorizer will depend only on > >> > Authorizer > >> > >> > > package. Third party implementations can have only the > authorizer > >> > pkg > >> > >> as > >> > >> > > dependency. core and client modules will also have to depend on > >> the > >> > >> > > authorizer with this approach. Do you see any issue with it? > >> > >> > > > >> > >> > >> > >> > >> > >> Authorizer interface will be updated to remove getter naming > >> > >> convention. > >> > >> > >> > >> > >> > >> > >> > >> > >> Now that this is Java do we still want to change to the Scala > >> > naming > >> > >> > >> convention? > >> > >> > >> > >> > >> > > Even in clients module I do not see getter naming convention > being > >> > >> > > followed, it is better to be consistent I guess. > >> > >> > > > >> > >> > >> > >> > >> > >> > >> > >> > >> Since we are completely rewriting the interface, can we add > some > >> > (at > >> > >> > least > >> > >> > >> one to start with) standard exceptions that each method is > >> > recommended > >> > >> > to > >> > >> > >> use/throw? This will help the server in KIP-4 provide > meaningful > >> > error > >> > >> > >> codes. KAFKA-3507 < > >> > https://issues.apache.org/jira/browse/KAFKA-3507> > >> > >> is > >> > >> > >> tracking it right now. > >> > >> > >> > >> > >> > > That should be good to have. Will include that. Thanks. > >> > >> > > > >> > >> > >> > >> > >> > >> Thanks, > >> > >> > >> Grant > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On Tue, Apr 19, 2016 at 9:48 AM, Ashish Singh < > >> asi...@cloudera.com > >> > > > >> > >> > >> wrote: > >> > >> > >> > >> > >> > >> > I have updated KIP-50 > >> > >> > >> > < > >> > >> > >> > > >> > >> > >> > >> > >> > > >> > >> > >> > > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-50+-+Move+Authorizer+to+a+separate+package > >> > >> > >> > > > >> > >> > >> > and PR <https://github.com/apache/kafka/pull/861> as per > >> recent > >> > >> > >> > discussions. Please take a look. > >> > >> > >> > > >> > >> > >> > @Harsha / Don, it would be nice if you guys can review the > KIP > >> > and > >> > >> PR > >> > >> > as > >> > >> > >> > well. > >> > >> > >> > > >> > >> > >> > > >> > >> > >> > On Mon, Apr 11, 2016 at 7:36 PM, Ashish Singh < > >> > asi...@cloudera.com> > >> > >> > >> wrote: > >> > >> > >> > > >> > >> > >> > > Yes, Jun. I would like to try get option 2 in, if > possible in > >> > >> 0.10. > >> > >> > I > >> > >> > >> am > >> > >> > >> > > not asking for delaying 0.10 for it, but some reviews and > >> early > >> > >> > >> feedback > >> > >> > >> > > would be great. At this point this is what I have in mind. > >> > >> > >> > > > >> > >> > >> > > 1. Move authorizer and related entities to its own > package. > >> > Note > >> > >> > that > >> > >> > >> I > >> > >> > >> > am > >> > >> > >> > > proposing to drop scala interface completely. Ranger team > is > >> > fine > >> > >> > >> with it > >> > >> > >> > > and I will update Sentry. > >> > >> > >> > > 2. The only new public method that will be added to > >> authorizer > >> > >> > >> interface > >> > >> > >> > > is description(). > >> > >> > >> > > 3. Update SimpleAclAuthorizer to use the new interface and > >> > >> classes. > >> > >> > >> > > > >> > >> > >> > > On Mon, Apr 11, 2016 at 6:38 PM, Jun Rao < > j...@confluent.io> > >> > >> wrote: > >> > >> > >> > > > >> > >> > >> > >> Ashish, > >> > >> > >> > >> > >> > >> > >> > >> So, you want to take a shot at option 2 for 0.10.0? > That's > >> > fine > >> > >> > with > >> > >> > >> me > >> > >> > >> > >> too. I am just not sure if we have enough time to think > >> > through > >> > >> the > >> > >> > >> > >> changes. > >> > >> > >> > >> > >> > >> > >> > >> Thanks, > >> > >> > >> > >> > >> > >> > >> > >> Jun > >> > >> > >> > >> > >> > >> > >> > >> On Mon, Apr 11, 2016 at 6:05 PM, Ashish Singh < > >> > >> asi...@cloudera.com > >> > >> > > > >> > >> > >> > >> wrote: > >> > >> > >> > >> > >> > >> > >> > >> > Hello Jun, > >> > >> > >> > >> > > >> > >> > >> > >> > The 3rd option will require Apache Sentry to go GA with > >> > current > >> > >> > >> > >> authorizer > >> > >> > >> > >> > interface, and at this point it seems that the > interface > >> > won't > >> > >> > last > >> > >> > >> > >> long. > >> > >> > >> > >> > Within a few months, Sentry will have to make a > breaking > >> > >> change. > >> > >> > I > >> > >> > >> do > >> > >> > >> > >> > understand that Kafka should not have to delay its > release > >> > due > >> > >> to > >> > >> > >> one > >> > >> > >> > of > >> > >> > >> > >> > the authorizer implementations. However, can we assist > >> > Sentry > >> > >> > >> users to > >> > >> > >> > >> > avoid that breaking upgrade? I think it is worth a > shot. > >> If > >> > the > >> > >> > >> > changes > >> > >> > >> > >> are > >> > >> > >> > >> > not done by 0.10 code freeze, then sure lets punt it to > >> next > >> > >> > >> release. > >> > >> > >> > >> Does > >> > >> > >> > >> > this seem reasonable to you? > >> > >> > >> > >> > > >> > >> > >> > >> > On Sun, Apr 10, 2016 at 11:42 AM, Jun Rao < > >> j...@confluent.io > >> > > > >> > >> > >> wrote: > >> > >> > >> > >> > > >> > >> > >> > >> > > Ashish, > >> > >> > >> > >> > > > >> > >> > >> > >> > > A 3rd option is to in 0.10.0, just sanity check the > >> > principal > >> > >> > >> type > >> > >> > >> > in > >> > >> > >> > >> the > >> > >> > >> > >> > > implementation of addAcls/removeAcls of Authorizer, > but > >> > don't > >> > >> > >> change > >> > >> > >> > >> the > >> > >> > >> > >> > > Authorizer api to add the getDescription() method. > This > >> > fixes > >> > >> > the > >> > >> > >> > >> > immediate > >> > >> > >> > >> > > issue that an acl rule with the wrong principal type > is > >> > >> > silently > >> > >> > >> > >> ignored. > >> > >> > >> > >> > > Knowing valid user types is nice, but not critical > (we > >> can > >> > >> > >> include > >> > >> > >> > the > >> > >> > >> > >> > > supported user type in the > >> > UnsupportedPrincipalTypeException > >> > >> > >> thrown > >> > >> > >> > >> from > >> > >> > >> > >> > > addAcls/removeAcls). This will give us more time to > >> clean > >> > up > >> > >> > the > >> > >> > >> > >> > Authorizer > >> > >> > >> > >> > > api post 0.10.0. > >> > >> > >> > >> > > > >> > >> > >> > >> > > Thanks > >> > >> > >> > >> > > > >> > >> > >> > >> > > Jun > >> > >> > >> > >> > > > >> > >> > >> > >> > > On Fri, Apr 8, 2016 at 9:04 AM, Ashish Singh < > >> > >> > >> asi...@cloudera.com> > >> > >> > >> > >> > wrote: > >> > >> > >> > >> > > > >> > >> > >> > >> > > > Thanks for the input Don. One of the possible paths > >> for > >> > >> > Option > >> > >> > >> 2 > >> > >> > >> > is > >> > >> > >> > >> to > >> > >> > >> > >> > > > completely drop Scala interface, would that be Ok > with > >> > you > >> > >> > >> folks? > >> > >> > >> > >> > > > > >> > >> > >> > >> > > > On Thursday, April 7, 2016, Don Bosco Durai < > >> > >> > bo...@apache.org> > >> > >> > >> > >> wrote: > >> > >> > >> > >> > > > > >> > >> > >> > >> > > > > Ranger team would prefer option #2. Right now, we > >> > have to > >> > >> > >> access > >> > >> > >> > >> some > >> > >> > >> > >> > > of > >> > >> > >> > >> > > > > the nested constants using constructs like > >> > >> Group$.MODULE$, > >> > >> > >> which > >> > >> > >> > >> is > >> > >> > >> > >> > not > >> > >> > >> > >> > > > > intuitive in Java. > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > Thanks > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > Bosco > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > On 4/7/16, 4:30 PM, "Ashish Singh" < > >> > asi...@cloudera.com > >> > >> > >> > >> > > <javascript:;>> > >> > >> > >> > >> > > > > wrote: > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > >Harsha/ Don, > >> > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >Are you guys OK with option 2? I am not aware of > >> all > >> > the > >> > >> > >> > existing > >> > >> > >> > >> > > > > >authorizer implementations, however ranger has > one > >> > for > >> > >> > sure. > >> > >> > >> > >> Getting > >> > >> > >> > >> > > > > direct > >> > >> > >> > >> > > > > >feedback from you guys will be really valuable. > >> > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >On Thu, Apr 7, 2016 at 3:52 PM, Ismael Juma < > >> > >> > >> ism...@juma.me.uk > >> > >> > >> > >> > > > > <javascript:;>> wrote: > >> > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> Hi Don, > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > > > > >> This is true in Java 7, but Java 8 introduces > >> > default > >> > >> > >> methods > >> > >> > >> > >> and > >> > >> > >> > >> > > this > >> > >> > >> > >> > > > > >> workaround is no longer required. During the > >> > >> Interceptor > >> > >> > >> KIP > >> > >> > >> > >> > > > > discussion, it > >> > >> > >> > >> > > > > >> was decided that it was fine to stick to > >> interfaces > >> > >> > given > >> > >> > >> > that > >> > >> > >> > >> we > >> > >> > >> > >> > > are > >> > >> > >> > >> > > > > >> likely to move to Java 8 in the nearish future > >> > >> (probably > >> > >> > >> no > >> > >> > >> > >> later > >> > >> > >> > >> > > than > >> > >> > >> > >> > > > > the > >> > >> > >> > >> > > > > >> Java 9 release). > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > > > > >> Ismael > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > > > > >> On Thu, Apr 7, 2016 at 11:36 PM, Don Bosco > Durai > >> < > >> > >> > >> > >> > bo...@apache.org > >> > >> > >> > >> > > > > <javascript:;>> wrote: > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > > > > >> > Hi Ashish > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > If we are going by option #2, then I can > >> suggest > >> > we > >> > >> > >> give an > >> > >> > >> > >> > > abstract > >> > >> > >> > >> > > > > >> > implementation of the Interface and > recommend > >> > anyone > >> > >> > >> > >> > implementing > >> > >> > >> > >> > > > > their > >> > >> > >> > >> > > > > >> own > >> > >> > >> > >> > > > > >> > plugin to extend from the abstract class, > >> rather > >> > >> than > >> > >> > >> > >> implement > >> > >> > >> > >> > > the > >> > >> > >> > >> > > > > >> > interface? > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > The advantage is, in the future if we add > add > >> any > >> > >> new > >> > >> > >> > >> methods in > >> > >> > >> > >> > > the > >> > >> > >> > >> > > > > >> > Interface (e.g. Similar to > getDescription()), > >> > then > >> > >> we > >> > >> > >> can > >> > >> > >> > >> give a > >> > >> > >> > >> > > > dummy > >> > >> > >> > >> > > > > >> > implementation of the new method and this > won’t > >> > >> break > >> > >> > >> the > >> > >> > >> > >> > > > compilation > >> > >> > >> > >> > > > > of > >> > >> > >> > >> > > > > >> > any external implementation. Else over the > time > >> > it > >> > >> > will > >> > >> > >> be > >> > >> > >> > >> > > > challenging > >> > >> > >> > >> > > > > >> for > >> > >> > >> > >> > > > > >> > anyone customizing the implementation to > keep > >> > track > >> > >> of > >> > >> > >> > >> changes > >> > >> > >> > >> > to > >> > >> > >> > >> > > > the > >> > >> > >> > >> > > > > >> > Interface. > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > Thanks > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > Bosco > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > On 4/7/16, 11:21 AM, "Ashish Singh" < > >> > >> > >> asi...@cloudera.com > >> > >> > >> > >> > > > > <javascript:;>> wrote: > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > >Hello Harsha, > >> > >> > >> > >> > > > > >> > > > >> > >> > >> > >> > > > > >> > >On Thu, Apr 7, 2016 at 11:03 AM, Harsha < > >> > >> > >> m...@harsha.io > >> > >> > >> > >> > > > > <javascript:;>> wrote: > >> > >> > >> > >> > > > > >> > > > >> > >> > >> > >> > > > > >> > >"My only ask is to have this in 0.10. As > Jay > >> > >> pointed > >> > >> > >> out, > >> > >> > >> > >> right > >> > >> > >> > >> > > now > >> > >> > >> > >> > > > > >> > >> there > >> > >> > >> > >> > > > > >> > >> are not many implementations out there, > we > >> > might > >> > >> > >> want to > >> > >> > >> > >> fix > >> > >> > >> > >> > it > >> > >> > >> > >> > > > > ASAP." > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > >> > > > > >> > >> Probably there aren't many > implementations > >> but > >> > >> > there > >> > >> > >> are > >> > >> > >> > >> lot > >> > >> > >> > >> > of > >> > >> > >> > >> > > > > users > >> > >> > >> > >> > > > > >> > >> using these implementations in production > >> > >> clusters. > >> > >> > >> > >> > > > > >> > >> Isn't this going to break the rolling > >> upgrade? > >> > >> > >> > >> > > > > >> > > > >> > >> > >> > >> > > > > >> > >It will and it is a concern, in my previous > >> > mail I > >> > >> > have > >> > >> > >> > >> > mentioned > >> > >> > >> > >> > > > > this > >> > >> > >> > >> > > > > >> as > >> > >> > >> > >> > > > > >> > >an issue if we choose to go this route. > >> > However, if > >> > >> > we > >> > >> > >> > >> actually > >> > >> > >> > >> > > > > decide > >> > >> > >> > >> > > > > >> to > >> > >> > >> > >> > > > > >> > >do this, I would say it is better to do it > >> > sooner > >> > >> > than > >> > >> > >> > >> later, > >> > >> > >> > >> > as > >> > >> > >> > >> > > > > fewer > >> > >> > >> > >> > > > > >> > >implementations will be affected. Below is > >> > excerpt > >> > >> > >> from my > >> > >> > >> > >> > > previous > >> > >> > >> > >> > > > > >> mail. > >> > >> > >> > >> > > > > >> > > > >> > >> > >> > >> > > > > >> > >Increase scope of KIP-50 to move authorizer > >> and > >> > >> > related > >> > >> > >> > >> classes > >> > >> > >> > >> > > to > >> > >> > >> > >> > > > a > >> > >> > >> > >> > > > > >> > >separate package. The new package will have > >> java > >> > >> > >> > interface. > >> > >> > >> > >> > This > >> > >> > >> > >> > > > will > >> > >> > >> > >> > > > > >> > allow > >> > >> > >> > >> > > > > >> > >implementations to not depend on kafka core > >> and > >> > >> just > >> > >> > on > >> > >> > >> > >> > > authorizer > >> > >> > >> > >> > > > > >> > package, > >> > >> > >> > >> > > > > >> > >make authorization interface follow kafka’s > >> > coding > >> > >> > >> > standards > >> > >> > >> > >> > and > >> > >> > >> > >> > > > will > >> > >> > >> > >> > > > > >> > allow > >> > >> > >> > >> > > > > >> > >java implementations to be cleaner. We can > >> > either > >> > >> > >> > completely > >> > >> > >> > >> > drop > >> > >> > >> > >> > > > > scala > >> > >> > >> > >> > > > > >> > >interface, which might be a pain for > existing > >> > >> > >> > >> implementations, > >> > >> > >> > >> > or > >> > >> > >> > >> > > > we > >> > >> > >> > >> > > > > can > >> > >> > >> > >> > > > > >> > >have scala interface wrap java interface. > >> Later > >> > >> > allows > >> > >> > >> a > >> > >> > >> > >> > cleaner > >> > >> > >> > >> > > > > >> > >deprecation path for existing scala > authorizer > >> > >> > >> interface, > >> > >> > >> > >> > however > >> > >> > >> > >> > > > it > >> > >> > >> > >> > > > > may > >> > >> > >> > >> > > > > >> > or > >> > >> > >> > >> > > > > >> > >may not be feasible as Kafka server will > have > >> to > >> > >> > >> somehow > >> > >> > >> > >> decide > >> > >> > >> > >> > > > which > >> > >> > >> > >> > > > > >> > >interface it should be looking for while > >> loading > >> > >> > >> > authorizer > >> > >> > >> > >> > > > > >> > implementation, > >> > >> > >> > >> > > > > >> > >this can probably be solved with a config > or > >> > some > >> > >> > >> > >> reflection. > >> > >> > >> > >> > If > >> > >> > >> > >> > > we > >> > >> > >> > >> > > > > >> choose > >> > >> > >> > >> > > > > >> > >to go this route, I can dig deeper. > >> > >> > >> > >> > > > > >> > > > >> > >> > >> > >> > > > > >> > >If we go with option 2 and commit on > getting > >> > this > >> > >> in > >> > >> > >> ASAP, > >> > >> > >> > >> > > > > preferably in > >> > >> > >> > >> > > > > >> > >0.10, there will be fewer implementations > that > >> > will > >> > >> > be > >> > >> > >> > >> > affected. > >> > >> > >> > >> > > > > >> > > > >> > >> > >> > >> > > > > >> > >and also moving to Java , > >> > >> > >> > >> > > > > >> > >> a authorizer implementation going to run > >> > inside a > >> > >> > >> > >> KafkaBroker > >> > >> > >> > >> > > > and I > >> > >> > >> > >> > > > > >> > >> don't see why this is necessary to move > to > >> > >> clients > >> > >> > >> > >> package. > >> > >> > >> > >> > > > > >> > >> Are we planning on introducing common > module > >> > to > >> > >> > have > >> > >> > >> it > >> > >> > >> > >> > > > > independent of > >> > >> > >> > >> > > > > >> > >> broker and client code? > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > >> > > > > >> > >Yes, I think that would take away the > >> > requirement > >> > >> of > >> > >> > >> > >> depending > >> > >> > >> > >> > on > >> > >> > >> > >> > > > > Kafka > >> > >> > >> > >> > > > > >> > >core from authorizer implementations. Do > you > >> > >> suggest > >> > >> > >> > >> otherwise? > >> > >> > >> > >> > > > > >> > > > >> > >> > >> > >> > > > > >> > > > >> > >> > >> > >> > > > > >> > >> -Harsha > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > >> > > > > >> > >> On Thu, Apr 7, 2016, at 10:52 AM, Ashish > >> Singh > >> > >> > wrote: > >> > >> > >> > >> > > > > >> > >> > We might want to take a call here. > >> Following > >> > >> are > >> > >> > >> the > >> > >> > >> > >> > options. > >> > >> > >> > >> > > > > >> > >> > > >> > >> > >> > >> > > > > >> > >> > 1. Let KIP-50 be the way it is, > i.e., > >> > just > >> > >> add > >> > >> > >> > >> > > > > getDescription() > >> > >> > >> > >> > > > > >> to > >> > >> > >> > >> > > > > >> > >> > existing scala authorizer > interface. It > >> > will > >> > >> > >> break > >> > >> > >> > >> > binary > >> > >> > >> > >> > > > > >> > >> > compatibility > >> > >> > >> > >> > > > > >> > >> > (only when using CLI and/or > >> AdminCommand > >> > >> from > >> > >> > >= > >> > >> > >> > 0.10 > >> > >> > >> > >> > > > against > >> > >> > >> > >> > > > > >> > >> > authorizer > >> > >> > >> > >> > > > > >> > >> > implementations based on 0.9.). If > we > >> go > >> > >> this > >> > >> > >> > route, > >> > >> > >> > >> it > >> > >> > >> > >> > > is a > >> > >> > >> > >> > > > > >> > simpler > >> > >> > >> > >> > > > > >> > >> > change > >> > >> > >> > >> > > > > >> > >> > and existing implementations won’t > have > >> > to > >> > >> > >> change > >> > >> > >> > >> > anything > >> > >> > >> > >> > > > on > >> > >> > >> > >> > > > > >> their > >> > >> > >> > >> > > > > >> > >> > end. > >> > >> > >> > >> > > > > >> > >> > 2. Increase scope of KIP-50 to move > >> > >> authorizer > >> > >> > >> and > >> > >> > >> > >> > related > >> > >> > >> > >> > > > > >> classes > >> > >> > >> > >> > > > > >> > to > >> > >> > >> > >> > > > > >> > >> > a > >> > >> > >> > >> > > > > >> > >> > separate package. The new package > will > >> > have > >> > >> > java > >> > >> > >> > >> > > interface. > >> > >> > >> > >> > > > > This > >> > >> > >> > >> > > > > >> > will > >> > >> > >> > >> > > > > >> > >> > allow > >> > >> > >> > >> > > > > >> > >> > implementations to not depend on > kafka > >> > core > >> > >> > and > >> > >> > >> > just > >> > >> > >> > >> on > >> > >> > >> > >> > > > > >> authorizer > >> > >> > >> > >> > > > > >> > >> > package, > >> > >> > >> > >> > > > > >> > >> > make authorization interface follow > >> > kafka’s > >> > >> > >> coding > >> > >> > >> > >> > > standards > >> > >> > >> > >> > > > > and > >> > >> > >> > >> > > > > >> > will > >> > >> > >> > >> > > > > >> > >> > allow > >> > >> > >> > >> > > > > >> > >> > java implementations to be cleaner. > We > >> > can > >> > >> > >> either > >> > >> > >> > >> > > completely > >> > >> > >> > >> > > > > drop > >> > >> > >> > >> > > > > >> > >> > scala > >> > >> > >> > >> > > > > >> > >> > interface, which might be a pain for > >> > >> existing > >> > >> > >> > >> > > > > implementations, or > >> > >> > >> > >> > > > > >> > we > >> > >> > >> > >> > > > > >> > >> > can > >> > >> > >> > >> > > > > >> > >> > have scala interface wrap java > >> interface. > >> > >> > Later > >> > >> > >> > >> allows a > >> > >> > >> > >> > > > > cleaner > >> > >> > >> > >> > > > > >> > >> > deprecation path for existing scala > >> > >> authorizer > >> > >> > >> > >> > interface, > >> > >> > >> > >> > > > > however > >> > >> > >> > >> > > > > >> > it > >> > >> > >> > >> > > > > >> > >> > may or > >> > >> > >> > >> > > > > >> > >> > may not be feasible as Kafka server > >> will > >> > >> have > >> > >> > to > >> > >> > >> > >> somehow > >> > >> > >> > >> > > > > decide > >> > >> > >> > >> > > > > >> > which > >> > >> > >> > >> > > > > >> > >> > interface it should be looking for > >> while > >> > >> > loading > >> > >> > >> > >> > > authorizer > >> > >> > >> > >> > > > > >> > >> > implementation, > >> > >> > >> > >> > > > > >> > >> > this can probably be solved with a > >> > config or > >> > >> > >> some > >> > >> > >> > >> > > > reflection. > >> > >> > >> > >> > > > > If > >> > >> > >> > >> > > > > >> we > >> > >> > >> > >> > > > > >> > >> > choose > >> > >> > >> > >> > > > > >> > >> > to go this route, I can dig deeper. > >> > >> > >> > >> > > > > >> > >> > > >> > >> > >> > >> > > > > >> > >> > If we decide to go with option 1, I > think > >> it > >> > >> > would > >> > >> > >> be > >> > >> > >> > >> fair > >> > >> > >> > >> > to > >> > >> > >> > >> > > > say > >> > >> > >> > >> > > > > >> that > >> > >> > >> > >> > > > > >> > >> > scala authorizer interface will be > around > >> > for > >> > >> > some > >> > >> > >> > >> time, as > >> > >> > >> > >> > > > there > >> > >> > >> > >> > > > > >> > will be > >> > >> > >> > >> > > > > >> > >> > more implementations relying on it. If > we > >> go > >> > >> with > >> > >> > >> > >> option 2 > >> > >> > >> > >> > > and > >> > >> > >> > >> > > > > >> commit > >> > >> > >> > >> > > > > >> > on > >> > >> > >> > >> > > > > >> > >> > getting this in ASAP, preferably in > 0.10, > >> > there > >> > >> > >> will > >> > >> > >> > be > >> > >> > >> > >> > fewer > >> > >> > >> > >> > > > > >> > >> > implementations that will be affected. > >> > >> > >> > >> > > > > >> > >> > > >> > >> > >> > >> > > > > >> > >> > *Another thing to notice is that scala > >> > >> authorizer > >> > >> > >> > >> interface > >> > >> > >> > >> > > is > >> > >> > >> > >> > > > > not > >> > >> > >> > >> > > > > >> > >> > annotated as unstable.* > >> > >> > >> > >> > > > > >> > >> > > >> > >> > >> > >> > > > > >> > >> > > >> > >> > >> > >> > > > > >> > >> > On Wed, Apr 6, 2016 at 9:41 AM, Ashish > >> > Singh < > >> > >> > >> > >> > > > > asi...@cloudera.com <javascript:;>> > >> > >> > >> > >> > > > > >> > >> wrote: > >> > >> > >> > >> > > > > >> > >> > > >> > >> > >> > >> > > > > >> > >> > > I see value in minimizing breaking > >> changes > >> > >> and > >> > >> > I > >> > >> > >> do > >> > >> > >> > >> not > >> > >> > >> > >> > > > oppose > >> > >> > >> > >> > > > > the > >> > >> > >> > >> > > > > >> > >> idea of > >> > >> > >> > >> > > > > >> > >> > > increasing scope of KIP-50 to move > auth > >> > >> > >> interface to > >> > >> > >> > >> > java. > >> > >> > >> > >> > > > > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > > As authorizer implementations do not > >> > really > >> > >> > need > >> > >> > >> to > >> > >> > >> > >> > depend > >> > >> > >> > >> > > on > >> > >> > >> > >> > > > > >> Kafka > >> > >> > >> > >> > > > > >> > >> core, > >> > >> > >> > >> > > > > >> > >> > > I would suggest that we keep > authorizer > >> > >> > interface > >> > >> > >> > and > >> > >> > >> > >> its > >> > >> > >> > >> > > > > >> components > >> > >> > >> > >> > > > > >> > >> in a > >> > >> > >> > >> > > > > >> > >> > > separate package. I share the concern > >> that > >> > >> > right > >> > >> > >> now > >> > >> > >> > >> > using > >> > >> > >> > >> > > > > >> Resource, > >> > >> > >> > >> > > > > >> > >> > > Operation, etc, in java > implementations > >> is > >> > >> > >> messy. I > >> > >> > >> > >> had > >> > >> > >> > >> > to > >> > >> > >> > >> > > > deal > >> > >> > >> > >> > > > > >> with > >> > >> > >> > >> > > > > >> > >> lot of > >> > >> > >> > >> > > > > >> > >> > > it while writing Apache Sentry > plugin. > >> > >> > >> > >> > > > > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > > My only ask is to have this in 0.10. > As > >> > Jay > >> > >> > >> pointed > >> > >> > >> > >> out, > >> > >> > >> > >> > > > right > >> > >> > >> > >> > > > > now > >> > >> > >> > >> > > > > >> > >> there > >> > >> > >> > >> > > > > >> > >> > > are not many implementations out > there, > >> we > >> > >> > might > >> > >> > >> > want > >> > >> > >> > >> to > >> > >> > >> > >> > > fix > >> > >> > >> > >> > > > it > >> > >> > >> > >> > > > > >> > ASAP. > >> > >> > >> > >> > > > > >> > >> I can > >> > >> > >> > >> > > > > >> > >> > > only speak of Sentry integration and > I > >> > think > >> > >> > 0.10 > >> > >> > >> > >> will be > >> > >> > >> > >> > > the > >> > >> > >> > >> > > > > best > >> > >> > >> > >> > > > > >> > for > >> > >> > >> > >> > > > > >> > >> such > >> > >> > >> > >> > > > > >> > >> > > a change, as I should be able to > adopt > >> the > >> > >> > >> changes > >> > >> > >> > in > >> > >> > >> > >> > > Sentry > >> > >> > >> > >> > > > > >> > >> integration > >> > >> > >> > >> > > > > >> > >> > > before a lot of users start using it. > >> > >> > >> > >> > > > > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > > On Wed, Apr 6, 2016 at 9:25 AM, > Ismael > >> > Juma < > >> > >> > >> > >> > > > ism...@juma.me.uk > >> > >> > >> > >> > > > > <javascript:;>> > >> > >> > >> > >> > > > > >> > wrote: > >> > >> > >> > >> > > > > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > >> It is small, but breaks binary > >> > >> compatibility. > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > >> > >> > > > > >> > >> > >> Ismael > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > >> > >> > > > > >> > >> > >> On Wed, Apr 6, 2016 at 5:20 PM, > Grant > >> > Henke > >> > >> < > >> > >> > >> > >> > > > > ghe...@cloudera.com <javascript:;> > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > >> wrote: > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > >> > >> > > > > >> > >> > >> > KIP-50 as defined is very small. I > >> > don't > >> > >> see > >> > >> > >> any > >> > >> > >> > >> harm > >> > >> > >> > >> > in > >> > >> > >> > >> > > > > >> putting > >> > >> > >> > >> > > > > >> > it > >> > >> > >> > >> > > > > >> > >> in > >> > >> > >> > >> > > > > >> > >> > >> as > >> > >> > >> > >> > > > > >> > >> > >> > is and then tackling the follow up > >> > work. > >> > >> > >> > >> > > > > >> > >> > >> > > >> > >> > >> > >> > > > > >> > >> > >> > > >> > >> > >> > >> > > > > >> > >> > >> > On Wed, Apr 6, 2016 at 11:16 AM, > >> Ismael > >> > >> > Juma < > >> > >> > >> > >> > > > > >> ism...@juma.me.uk <javascript:;>> > >> > >> > >> > >> > > > > >> > >> wrote: > >> > >> > >> > >> > > > > >> > >> > >> > > >> > >> > >> > >> > > > > >> > >> > >> > > Thanks Grant. I wonder if KIP-50 > >> > should > >> > >> > >> just be > >> > >> > >> > >> done > >> > >> > >> > >> > > as > >> > >> > >> > >> > > > > part > >> > >> > >> > >> > > > > >> of > >> > >> > >> > >> > > > > >> > >> this > >> > >> > >> > >> > > > > >> > >> > >> > work. > >> > >> > >> > >> > > > > >> > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > >> > > Ismael > >> > >> > >> > >> > > > > >> > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > >> > > On Wed, Apr 6, 2016 at 5:12 PM, > >> Grant > >> > >> > Henke > >> > >> > >> < > >> > >> > >> > >> > > > > >> > ghe...@cloudera.com <javascript:;>> > >> > >> > >> > >> > > > > >> > >> > >> wrote: > >> > >> > >> > >> > > > > >> > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > >> > > > My work with KIP-4 found that > >> many > >> > of > >> > >> > the > >> > >> > >> > Scala > >> > >> > >> > >> > > > classes > >> > >> > >> > >> > > > > >> used > >> > >> > >> > >> > > > > >> > in > >> > >> > >> > >> > > > > >> > >> the > >> > >> > >> > >> > > > > >> > >> > >> > > > Authorizer interface are > needed > >> in > >> > the > >> > >> > >> > Clients > >> > >> > >> > >> > > package > >> > >> > >> > >> > > > > when > >> > >> > >> > >> > > > > >> > >> adding > >> > >> > >> > >> > > > > >> > >> > >> the > >> > >> > >> > >> > > > > >> > >> > >> > > > various ACL requests and > >> > responses. I > >> > >> > also > >> > >> > >> > >> found > >> > >> > >> > >> > > that > >> > >> > >> > >> > > > we > >> > >> > >> > >> > > > > >> > don't > >> > >> > >> > >> > > > > >> > >> have > >> > >> > >> > >> > > > > >> > >> > >> > > > standard Exceptions defined > for > >> the > >> > >> > >> > authorizer > >> > >> > >> > >> > > > > interface. > >> > >> > >> > >> > > > > >> > This > >> > >> > >> > >> > > > > >> > >> means > >> > >> > >> > >> > > > > >> > >> > >> > that > >> > >> > >> > >> > > > > >> > >> > >> > > > when I add the Authorizer > calls > >> to > >> > the > >> > >> > >> broker > >> > >> > >> > >> and > >> > >> > >> > >> > > wire > >> > >> > >> > >> > > > > >> > >> protocols all > >> > >> > >> > >> > > > > >> > >> > >> > > > exceptions will be reported > as an > >> > >> > "Unknown > >> > >> > >> > >> Error" > >> > >> > >> > >> > > back > >> > >> > >> > >> > > > > to > >> > >> > >> > >> > > > > >> the > >> > >> > >> > >> > > > > >> > >> user > >> > >> > >> > >> > > > > >> > >> > >> via > >> > >> > >> > >> > > > > >> > >> > >> > > the > >> > >> > >> > >> > > > > >> > >> > >> > > > wire protocol. > >> > >> > >> > >> > > > > >> > >> > >> > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > I have written more about it > on > >> the > >> > >> > KIP-4 > >> > >> > >> > wiki > >> > >> > >> > >> and > >> > >> > >> > >> > > > > created > >> > >> > >> > >> > > > > >> > >> jiras to > >> > >> > >> > >> > > > > >> > >> > >> > track > >> > >> > >> > >> > > > > >> > >> > >> > > > those issues (See below). I > think > >> > we > >> > >> > >> should > >> > >> > >> > >> wrap > >> > >> > >> > >> > up > >> > >> > >> > >> > > > this > >> > >> > >> > >> > > > > >> KIP > >> > >> > >> > >> > > > > >> > as > >> > >> > >> > >> > > > > >> > >> is > >> > >> > >> > >> > > > > >> > >> > >> and > >> > >> > >> > >> > > > > >> > >> > >> > > > tackle the Java/Exception > changes > >> > as a > >> > >> > >> part > >> > >> > >> > of > >> > >> > >> > >> > those > >> > >> > >> > >> > > > > >> > jiras/kips. > >> > >> > >> > >> > > > > >> > >> > >> > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > - KIP-4 "Follow Up Changes" > >> > >> > >> > >> > > > > >> > >> > >> > > > < > >> > >> > >> > >> > > > > >> > >> > >> > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > >> > > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > >> > >> > >> > >> > > > >> > >> > >> > >> > > >> > >> > >> > >> > >> > >> > >> > > >> > >> > >> > >> > >> > > >> > >> > >> > > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-4+-+Command+line+and+centralized+administrative+operations#KIP-4-Commandlineandcentralizedadministrativeoperations-FollowUpChangesfollow-up-changes > >> > >> > >> > >> > > > > >> > >> > >> > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > - KAFKA-3509 < > >> > >> > >> > >> > > > > >> > >> > >> > https://issues.apache.org/jira/browse/KAFKA-3509 > >> > >> >: > >> > >> > >> > >> > > > > >> > >> > >> > > > Provide > >> > >> > >> > >> > > > > >> > >> > >> > > > an Authorizer interface > using > >> > the > >> > >> > Java > >> > >> > >> > >> client > >> > >> > >> > >> > > > > enumerator > >> > >> > >> > >> > > > > >> > >> classes > >> > >> > >> > >> > > > > >> > >> > >> > > > - KAFKA-3507 < > >> > >> > >> > >> > > > > >> > >> > >> > https://issues.apache.org/jira/browse/KAFKA-3507 > >> > >> >: > >> > >> > >> > >> > > > > >> > >> > >> > > Define > >> > >> > >> > >> > > > > >> > >> > >> > > > standard exceptions for the > >> > >> > Authorizer > >> > >> > >> > >> > interface > >> > >> > >> > >> > > > > >> > >> > >> > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > Thank you, > >> > >> > >> > >> > > > > >> > >> > >> > > > Grant > >> > >> > >> > >> > > > > >> > >> > >> > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > On Wed, Apr 6, 2016 at 10:58 > AM, > >> > Jay > >> > >> > >> Kreps < > >> > >> > >> > >> > > > > >> j...@confluent.io <javascript:;> > >> > >> > >> > >> > > > > >> > > > >> > >> > >> > >> > > > > >> > >> > >> wrote: > >> > >> > >> > >> > > > > >> > >> > >> > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > Hey Ismael, > >> > >> > >> > >> > > > > >> > >> > >> > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > Yeah I think this is a minor > >> > >> > cleanliness > >> > >> > >> > >> thing. > >> > >> > >> > >> > > > Since > >> > >> > >> > >> > > > > >> this > >> > >> > >> > >> > > > > >> > is > >> > >> > >> > >> > > > > >> > >> kind > >> > >> > >> > >> > > > > >> > >> > >> > of a > >> > >> > >> > >> > > > > >> > >> > >> > > > > power user interface I don't > >> feel > >> > >> > >> strongly > >> > >> > >> > >> > either > >> > >> > >> > >> > > > way. > >> > >> > >> > >> > > > > >> > >> > >> > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > My motivation with Scala is > >> just > >> > >> that > >> > >> > >> we've > >> > >> > >> > >> > tried > >> > >> > >> > >> > > to > >> > >> > >> > >> > > > > move > >> > >> > >> > >> > > > > >> > to > >> > >> > >> > >> > > > > >> > >> > >> having > >> > >> > >> > >> > > > > >> > >> > >> > the > >> > >> > >> > >> > > > > >> > >> > >> > > > > public interfaces be Java, > and > >> > as a > >> > >> > >> group > >> > >> > >> > we > >> > >> > >> > >> > > > > definitely > >> > >> > >> > >> > > > > >> > >> struggled > >> > >> > >> > >> > > > > >> > >> > >> a > >> > >> > >> > >> > > > > >> > >> > >> > lot > >> > >> > >> > >> > > > > >> > >> > >> > > > > with understanding and > >> > maintaining > >> > >> > Scala > >> > >> > >> > >> > > > > compatibility in > >> > >> > >> > >> > > > > >> > the > >> > >> > >> > >> > > > > >> > >> > >> older > >> > >> > >> > >> > > > > >> > >> > >> > > > > clients. > >> > >> > >> > >> > > > > >> > >> > >> > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > -Jay > >> > >> > >> > >> > > > > >> > >> > >> > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > On Tue, Apr 5, 2016 at 11:46 > >> PM, > >> > >> > Ismael > >> > >> > >> > Juma > >> > >> > >> > >> < > >> > >> > >> > >> > > > > >> > >> ism...@juma.me.uk <javascript:;>> > >> > >> > >> > >> > > > > >> > >> > >> > > wrote: > >> > >> > >> > >> > > > > >> > >> > >> > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > Hi Jay, > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > On Wed, Apr 6, 2016 at > 3:48 > >> AM, > >> > >> Jay > >> > >> > >> > Kreps < > >> > >> > >> > >> > > > > >> > j...@confluent.io <javascript:;> > >> > >> > >> > >> > > > > >> > >> > > >> > >> > >> > >> > > > > >> > >> > >> > wrote: > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > Given that we're > breaking > >> > >> > >> compatibility > >> > >> > >> > >> > anyway > >> > >> > >> > >> > > > > should > >> > >> > >> > >> > > > > >> > we: > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > We are not breaking source > >> > >> > >> compatibility > >> > >> > >> > >> since > >> > >> > >> > >> > > the > >> > >> > >> > >> > > > > new > >> > >> > >> > >> > > > > >> > >> method > >> > >> > >> > >> > > > > >> > >> > >> has a > >> > >> > >> > >> > > > > >> > >> > >> > > > > default > >> > >> > >> > >> > > > > >> > >> > >> > > > > > implementation. I take it > >> that > >> > you > >> > >> > >> mean > >> > >> > >> > >> binary > >> > >> > >> > >> > > > > >> > >> compatibility? > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > 1. Remove the get > prefix on > >> > this > >> > >> > >> method > >> > >> > >> > >> and > >> > >> > >> > >> > > the > >> > >> > >> > >> > > > > >> > existing > >> > >> > >> > >> > > > > >> > >> one > >> > >> > >> > >> > > > > >> > >> > >> > which > >> > >> > >> > >> > > > > >> > >> > >> > > > > > violate > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > our own code style > >> guidelines > >> > >> > (Oops! > >> > >> > >> > >> Kind of > >> > >> > >> > >> > > sad > >> > >> > >> > >> > > > > we > >> > >> > >> > >> > > > > >> > went > >> > >> > >> > >> > > > > >> > >> > >> through > >> > >> > >> > >> > > > > >> > >> > >> > > the > >> > >> > >> > >> > > > > >> > >> > >> > > > > > whole > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > KIP process and no one > even > >> > >> > flagged > >> > >> > >> > this) > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > I did flag this during the > >> > >> > discussion > >> > >> > >> and > >> > >> > >> > >> > Ashish > >> > >> > >> > >> > > > > said > >> > >> > >> > >> > > > > >> he > >> > >> > >> > >> > > > > >> > >> would > >> > >> > >> > >> > > > > >> > >> > >> > change > >> > >> > >> > >> > > > > >> > >> > >> > > > it > >> > >> > >> > >> > > > > >> > >> > >> > > > > if > >> > >> > >> > >> > > > > >> > >> > >> > > > > > other people felt that it > >> > should > >> > >> be > >> > >> > >> > >> changed. > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > 2. Move the interface > out > >> of > >> > >> scala > >> > >> > >> to > >> > >> > >> > be > >> > >> > >> > >> a > >> > >> > >> > >> > > > normal > >> > >> > >> > >> > > > > >> Java > >> > >> > >> > >> > > > > >> > >> > >> interface > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > This breaks source > >> > compatibility > >> > >> > but > >> > >> > >> > >> > probably > >> > >> > >> > >> > > > > what we > >> > >> > >> > >> > > > > >> > >> should > >> > >> > >> > >> > > > > >> > >> > >> have > >> > >> > >> > >> > > > > >> > >> > >> > > > done > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > originally I suspect. > >> > Probably > >> > >> > there > >> > >> > >> > are > >> > >> > >> > >> few > >> > >> > >> > >> > > > > enough > >> > >> > >> > >> > > > > >> > >> > >> > implementations > >> > >> > >> > >> > > > > >> > >> > >> > > > of > >> > >> > >> > >> > > > > >> > >> > >> > > > > > this > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > that it is better to > just > >> rip > >> > >> the > >> > >> > >> > bandaid > >> > >> > >> > >> > off. > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > Can you please explain the > >> > >> > >> motivation? It > >> > >> > >> > >> did > >> > >> > >> > >> > > come > >> > >> > >> > >> > > > > up > >> > >> > >> > >> > > > > >> in > >> > >> > >> > >> > > > > >> > >> > >> previous > >> > >> > >> > >> > > > > >> > >> > >> > > > > > discussions that some > things > >> > like > >> > >> > >> > Operation > >> > >> > >> > >> > and > >> > >> > >> > >> > > > > >> > ResourceType > >> > >> > >> > >> > > > > >> > >> > >> should > >> > >> > >> > >> > > > > >> > >> > >> > > be > >> > >> > >> > >> > > > > >> > >> > >> > > > in > >> > >> > >> > >> > > > > >> > >> > >> > > > > > the clients library, but > not > >> > >> > >> Authorizer > >> > >> > >> > >> > itself. > >> > >> > >> > >> > > > Are > >> > >> > >> > >> > > > > we > >> > >> > >> > >> > > > > >> > >> saying > >> > >> > >> > >> > > > > >> > >> > >> that > >> > >> > >> > >> > > > > >> > >> > >> > > any > >> > >> > >> > >> > > > > >> > >> > >> > > > > > pluggable interface > should be > >> > in > >> > >> > Java > >> > >> > >> so > >> > >> > >> > >> that > >> > >> > >> > >> > > > users > >> > >> > >> > >> > > > > can > >> > >> > >> > >> > > > > >> > >> > >> implement > >> > >> > >> > >> > > > > >> > >> > >> > it > >> > >> > >> > >> > > > > >> > >> > >> > > > > > without including the > Scala > >> > >> library? > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > Grant, you originally > >> suggested > >> > >> that > >> > >> > >> some > >> > >> > >> > >> > things > >> > >> > >> > >> > > > > would > >> > >> > >> > >> > > > > >> > have > >> > >> > >> > >> > > > > >> > >> to > >> > >> > >> > >> > > > > >> > >> > >> be > >> > >> > >> > >> > > > > >> > >> > >> > in > >> > >> > >> > >> > > > > >> > >> > >> > > > the > >> > >> > >> > >> > > > > >> > >> > >> > > > > > Java side as well. Can you > >> > please > >> > >> > >> > >> elaborate on > >> > >> > >> > >> > > > this? > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > Ismael > >> > >> > >> > >> > > > > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > -- > >> > >> > >> > >> > > > > >> > >> > >> > > > Grant Henke > >> > >> > >> > >> > > > > >> > >> > >> > > > Software Engineer | Cloudera > >> > >> > >> > >> > > > > >> > >> > >> > > > gr...@cloudera.com > >> <javascript:;> > >> > | > >> > >> > >> > >> > > > twitter.com/gchenke > >> > >> > >> > >> > > > > | > >> > >> > >> > >> > > > > >> > >> > >> linkedin.com/in/granthenke > >> > >> > >> > >> > > > > >> > >> > >> > > > > >> > >> > >> > >> > > > > >> > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > >> > > >> > >> > >> > >> > > > > >> > >> > >> > > >> > >> > >> > >> > > > > >> > >> > >> > > >> > >> > >> > >> > > > > >> > >> > >> > -- > >> > >> > >> > >> > > > > >> > >> > >> > Grant Henke > >> > >> > >> > >> > > > > >> > >> > >> > Software Engineer | Cloudera > >> > >> > >> > >> > > > > >> > >> > >> > gr...@cloudera.com > <javascript:;> | > >> > >> > >> > >> > twitter.com/gchenke > >> > >> > >> > >> > > | > >> > >> > >> > >> > > > > >> > >> linkedin.com/in/granthenke > >> > >> > >> > >> > > > > >> > >> > >> > > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > >> > >> > > > > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > > -- > >> > >> > >> > >> > > > > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > > Regards, > >> > >> > >> > >> > > > > >> > >> > > Ashish > >> > >> > >> > >> > > > > >> > >> > > > >> > >> > >> > >> > > > > >> > >> > > >> > >> > >> > >> > > > > >> > >> > > >> > >> > >> > >> > > > > >> > >> > > >> > >> > >> > >> > > > > >> > >> > -- > >> > >> > >> > >> > > > > >> > >> > > >> > >> > >> > >> > > > > >> > >> > Regards, > >> > >> > >> > >> > > > > >> > >> > Ashish > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > >> > > > > >> > > > >> > >> > >> > >> > > > > >> > >-- > >> > >> > >> > >> > > > > >> > > > >> > >> > >> > >> > > > > >> > >Regards, > >> > >> > >> > >> > > > > >> > >Ashish > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > > >> > >> > >> > >> > > > > >> > >> > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >-- > >> > >> > >> > >> > > > > > > >> > >> > >> > >> > > > > >Regards, > >> > >> > >> > >> > > > > >Ashish > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > >> > >> > >> > >> > > > -- > >> > >> > >> > >> > > > Ashish 🎤h > >> > >> > >> > >> > > > > >> > >> > >> > >> > > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > > >> > >> > >> > >> > -- > >> > >> > >> > >> > > >> > >> > >> > >> > Regards, > >> > >> > >> > >> > Ashish > >> > >> > >> > >> > > >> > >> > >> > >> > >> > >> > >> > > > >> > >> > >> > > > >> > >> > >> > > > >> > >> > >> > > -- > >> > >> > >> > > > >> > >> > >> > > Regards, > >> > >> > >> > > Ashish > >> > >> > >> > > > >> > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> > >> > >> > -- > >> > >> > >> > > >> > >> > >> > Regards, > >> > >> > >> > Ashish > >> > >> > >> > > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> > >> Grant Henke > >> > >> > >> Software Engineer | Cloudera > >> > >> > >> gr...@cloudera.com | twitter.com/gchenke | > >> > linkedin.com/in/granthenke > >> > >> > >> > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > -- > >> > >> > > > >> > >> > > Regards, > >> > >> > > Ashish > >> > >> > > > >> > >> > > >> > >> > > >> > >> > > >> > >> > -- > >> > >> > > >> > >> > Regards, > >> > >> > Ashish > >> > >> > > >> > >> > >> > > > >> > > > >> > > > >> > > -- > >> > > > >> > > Regards, > >> > > Ashish > >> > > >> > > >> > -- Regards, Ashish
