Hi Mickael,
Unfortunately, it's not actively being worked on, but I welcome anyone to
come forward. Otherwise it's on my list that I'll eventually get around to.
Currently the logic replicates what was being done historically with the
quota configuration management, and is therefore compatible wi
Hi,
Is anyone actively working on adding support for custom quotas callbacks?
We should really try to get this in soon as otherwise this KIP is not
usable in environments with custom quotas. It's unfortunate to have
the capability on the client-side but no support on brokers.
Thanks
On Sat, Jan
Hi Brian,
Thanks for the KIP. I think it looks good and ready for a vote!
One nitpick: we try to avoid being too Java-specific when describing the
protocol. Rather than referencing java.lang.Double, it would be more helpful
to say something equivalent, like "the float is serialized as a 64-b
Thanks for reviewing, Anna,
In the describe call, the idea is that the API will match the QuotaFilters,
which can be specified in two ways for your example (filter is a type and a
matching string):
1) (USER="user-1") returns both
2) (USER="user-1", CLIENT_ID="") returns just /config/users/”user-1
Hi Brian,
The KIP looks good!
I have one clarification question regarding the distinction between
describe and resolve API. Suppose I set request quota for
/config/users/”user-1”/clients/"client-1" to 100 and request quota for
/config/users/”user-1” to 200. Is this correct that describeClientQuot
My apologies, Rajini. My hasty edits omitted a couple spots. I've done a
more thorough scan and should have cleaned up (1) and (2).
For (3), Longs are chosen because that's what the ConfigCommand currently
uses, and because there's no floating point type in the RPC protocol. Longs
didn't seem to b
Thanks Brian. Looks good.
Just a few minor points:
1) We can remove *public ResolveClientQuotasOptions
setOmitOverriddenValues(boolean omitOverriddenValues); *
2) Under ClientQuotasCommand, the three items are List/Describe/Alter,
rename to match the new naming for operations?
3) Request quota co
Thanks again, Rajini,
Units will have to be implemented on a per-config basis, then. I've removed
all language reference to units and replaced QuotaKey -> String (config
name). I've also renamed DescribeEffective -> Resolve, and replaced --list
with --describe, and --describe to --resolve to be co
Hi Brian,
Thanks for the responses.
4) Yes, agree that it would be simpler to leave units out of the initial
design. We currently have units that are interpreted by the configurable
callback. The default callback interprets the value as
per-broker-bytes-per-second and per-broker-percentage-cores.
Thanks Rajini,
1) Good catch, fixed.
2) You're right. We'd need to extend ClientQuotaCallback#quotaLimit or add
an alternate function. For the sake of an initial implementation, I'm going
to remove '--show-overridden', and a subsequent KIP will have to propose an
extents to ClientQuotaCallback to
Hi Brian,
Thanks for the KIP. Looks good, hope we finally get this in!
A few comments:
1) All the Admin interface methods seem to be using method names starting
with upper-case letter, should be lower-case to be follow conventions.
2) Effective quotas returns not only the actual effective quota,
Hi Jason,
I agree on (1). It was Colin's original suggestion, too, but he had changed
his mind in preference for enums. Strings are the more generic way for now,
so hopefully Colin can share his thinking when he's back. The QuotaFilter
usage was an error, this has been corrected.
For (2), the con
Hi Brian,
Thanks for the proposal! I have a couple comments/questions:
1. I'm having a hard time understanding the point of `QuotaEntity.Type`. It
sounds like this might be just for convenience since the APIs are using
string types. If so, I think it's a bit misleading to represent it as an
enum.
Thanks Colin, I've updated the KIP with the relevant changes.
On Fri, Jan 17, 2020 at 10:17 AM Colin McCabe wrote:
> I thought about this a little bit more, and maybe we can leave in the
> enums rather than going with strings. But we need to have an "UNKNOWN"
> value for all the enums, so that
Hi Brian,
Thanks again for working on this. It's looking good.
I thought about this a little bit more, and maybe we can leave in the enums
rather than going with strings. But we need to have an "UNKNOWN" value for all
the enums, so that if a value that the client doesn't understand is returne
Hi Colin,
Your feedback is appreciated, thank you.
On Tue, Jan 14, 2020 at 11:34 AM Colin McCabe wrote:
> This is probably a nitpick, but it would be nice to specify that this list
> is in order of highest priority to lowest.
>
Done.
> Hmm. Maybe --show-overridden or --include-overridden is
Hi Brian,
Thanks for the KIP.
The KIP says:
> As represented by the current ZK node structure, the order in which quotas
> are matched are as follows. Note is a specified user principal,
> is a specified client ID, and is a special default
> user/client ID that matches to all users or
Hello all,
I'm reviving the discussion for adding a quotas API to the admin client by
submitting a new proposal. There are some notable changes from previous
attempts, namely a way to deduce the effective quota for a client (entity),
a way to query for configured quotas, and the concept of "units"
18 matches
Mail list logo
