Yes - we will be using the quota manager integration with KM. The main reason for using KM is that the end-state we agreed on is for all metrics to move over to KM and remove our dependency on YM completely.
Thanks, Joel On Tue, Mar 31, 2015 at 09:51:56PM +0000, Jiangjie Qin wrote: > Thanks for clarification Joel. Just wondering if we are going to depend on > any KM specific features? Asking this because KM metric config has quota > in side it. > > On 3/31/15, 1:53 PM, "Joel Koshy" <[email protected]> wrote: > > >We will be using KM for quota'ing on the new client-id-specific > >metrics. > > > >On Tue, Mar 31, 2015 at 08:44:44PM +0000, Jiangjie Qin wrote: > >> 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 > >> > > > -- Joel
