Right, if this KIP is subsumed by KIP-7, perhaps we just need to wait until KIP-7 is done? If we add the small change now, we will have to worry about migrating existing users and deprecating some configs when KIP-7 is done.
Thanks, Jun On Fri, Mar 20, 2015 at 10:36 AM, Parth Brahmbhatt < pbrahmbh...@hortonworks.com> wrote: > I am not entirely sure what you mean by integrating KIP-7 work with > KAFKA-1688. Wouldn¹t the work done as part of KIP-7 become obsolete once > KAFKA-1688 is done? Multiple ways of controlling these authorization just > seems extra configuration that will confuse admins/users. > > If timing is the only issue don¹t you think its better to focus our energy > on getting 1688 done faster which seem to be the longer term goal anyways? > > Thanks > Parth > > On 3/20/15, 10:28 AM, "Jeff Holoman" <jholo...@cloudera.com> wrote: > > >Hey Jun, > > > >The intent was for the same functionality to be utilized when 1688 is > >done, > >as mentioned in the KIP: > > > >"The broader security initiative <http://kafka-1682/> will add more > robust > >controls for these types of environments, and this proposal could be > >integrated with that work at the appropriate time. This is also the > >specific request of a large financial services company." > > > >I don't think including the functionality now (as it's relatively simple) > >would preclude integration into 1688. At that point the implementation of > >the check might change, but as it's a broker config, there shouldn't be > >concerns about backward compatibility. > > > >Hope that helps > > > >Thanks > > > >Jeff > > > >On Fri, Mar 20, 2015 at 12:26 PM, Jun Rao <j...@confluent.io> wrote: > > > >> Yes, we can discuss the implementation separately. > >> > >> As for the proposal itself, have you looked at KAFKA-1688? Could this > >>just > >> be a special case for authorization and be included there? > >> > >> Thanks, > >> > >> Jun > >> > >> On Wed, Mar 18, 2015 at 6:26 PM, Jeff Holoman <jholo...@cloudera.com> > >> wrote: > >> > >> > One other thought. Does the timing of the implementation (or lack > >> thereof) > >> > affect the proposal? It seems like the question you are asking is an > >> > implementation detail in terms of when the work would be done. If > >>there > >> > isn't really support for the KIP that's ok, just wanting to make sure > >>we > >> > are segmenting the vote for the KIP from concerns about implementation > >> > timing. > >> > > >> > Thanks! > >> > > >> > Jeff > >> > > >> > On Wed, Mar 18, 2015 at 9:22 PM, Jeff Holoman <jholo...@cloudera.com> > >> > wrote: > >> > > >> > > Hey Jun thanks for the comment. > >> > > > >> > > Is the plan to re-factor the SocketServer implementation > >>significantly? > >> > > The current check is just in the acceptor. Does this change with the > >> > > refactor? > >> > > > >> > > Thanks > >> > > > >> > > Jeff > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > On Wed, Mar 18, 2015 at 7:25 PM, Jun Rao <j...@confluent.io> wrote: > >> > > > >> > >> The proposal sounds reasonable. Timing wise, since we plan to > >>refactor > >> > the > >> > >> network layer code in the broker, perhaps this can wait until > >> KAFKA-1928 > >> > >> is > >> > >> done? > >> > >> > >> > >> Thanks, > >> > >> > >> > >> Jun > >> > >> > >> > >> On Tue, Mar 17, 2015 at 6:56 AM, Jeff Holoman > >><jholo...@cloudera.com> > >> > >> wrote: > >> > >> > >> > >> > bump > >> > >> > > >> > >> > On Tue, Mar 3, 2015 at 8:12 PM, Jeff Holoman > >><jholo...@cloudera.com > >> > > >> > >> > wrote: > >> > >> > > >> > >> > > Guozhang, > >> > >> > > > >> > >> > > The way the patch is implemented, the check is done in the > >> acceptor > >> > >> > thread > >> > >> > > accept() method of the Socket Server, just before > >> connectionQuotas. > >> > >> > > > >> > >> > > Thanks > >> > >> > > > >> > >> > > Jeff > >> > >> > > > >> > >> > > On Tue, Mar 3, 2015 at 7:59 PM, Guozhang Wang > >><wangg...@gmail.com > >> > > >> > >> > wrote: > >> > >> > > > >> > >> > >> Jeff, > >> > >> > >> > >> > >> > >> I am wondering if the IP filtering rule can be enforced at the > >> > socket > >> > >> > >> server level instead of the Kafka API level? > >> > >> > >> > >> > >> > >> Guozhang > >> > >> > >> > >> > >> > >> On Tue, Mar 3, 2015 at 2:24 PM, Jiangjie Qin > >> > >> <j...@linkedin.com.invalid > >> > >> > > > >> > >> > >> wrote: > >> > >> > >> > >> > >> > >> > +1 (non-binding) > >> > >> > >> > > >> > >> > >> > On 3/3/15, 1:17 PM, "Gwen Shapira" <gshap...@cloudera.com> > >> > wrote: > >> > >> > >> > > >> > >> > >> > >+1 (non-binding) > >> > >> > >> > > > >> > >> > >> > >On Tue, Mar 3, 2015 at 12:44 PM, Jeff Holoman < > >> > >> jholo...@cloudera.com > >> > >> > > > >> > >> > >> > >wrote: > >> > >> > >> > >> Details in the wiki. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > >> > >> > >> > >> > >> > > >> > >> > >> > > >> > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-7+-+Security+-+IP+F > >> > >> > >> > >>iltering > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> > >> > >> Jeff Holoman > >> > >> > >> > >> Systems Engineer > >> > >> > >> > > >> > >> > >> > > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> > >> -- Guozhang > >> > >> > >> > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > -- > >> > >> > > Jeff Holoman > >> > >> > > Systems Engineer > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > >> > >> > > >> > >> > -- > >> > >> > Jeff Holoman > >> > >> > Systems Engineer > >> > >> > > >> > >> > >> > > > >> > > > >> > > > >> > > -- > >> > > Jeff Holoman > >> > > Systems Engineer > >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > -- > >> > Jeff Holoman > >> > Systems Engineer > >> > > >> > > > > > > > >-- > >Jeff Holoman > >Systems Engineer > >
