Thanks a lot for the summary, Gwen! About the Quota, does that mean the first quota implementation will be based on YM? I¹m thinking can we pursue a quota solution that has a loose coupling with metrics interfaces? Like something operating system does for FUSE, so we don¹t need to care about which underlying metric we use. In that case, we can implement the Quota base on KM and wrap YM to resemble KM. Quota management itself can also be extracted as a separate package in this case.
Jiangjie (Becket) Qin On 3/31/15, 12:04 PM, "Gwen Shapira" <[email protected]> wrote: >Hi, > >Short notes from today's discussion for those who missed it. >Attendees, feel free to correct or add: > >KIP-4: >* Agreed to bump TopicMetadataRequest version, leave V0 with automatic >topic-creation and add warnings that we are deprecating the feature in >future releases. >* Agreed to document all API additions and how client developers will >use new API. >* Decided not to have the server parse regular expressions when listing >topics > >Quotas and Metrics: >* Quotas should use new KM metrics - those will be missing from >existing reporters >* Security requires re-using client classes in core and this will >bring more KM metrics >* We don¹t want to block security with metrics requirement >* So we can shim KM into YM for security >* After security we can start replacing everything > >KIP-5: >Shaping up to be a very large feature. Decided that Quotas won¹t need >to wait on this. Waiting for a more in-depth design doc > >KIP-13: >- Depends on KIP-4 for admin side > >KIP-11: >- Want to get the network client reuse done first - Gwen needs to >check if its possible to share >- blocked on generic channel implementation > >Others: >* Agreed to use KIP call to discuss JIRAs blocked on reviews >* New replica lag is almost ready! > >Gwen
