From dev-return-110444-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Tue Jan 14 19:34:33 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id B7CD618061A for ; Tue, 14 Jan 2020 20:34:32 +0100 (CET) Received: (qmail 84530 invoked by uid 500); 14 Jan 2020 19:34:31 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 84518 invoked by uid 99); 14 Jan 2020 19:34:31 -0000 Received: from Unknown (HELO mailrelay1-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jan 2020 19:34:31 +0000 Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 37CFB1059 for ; Tue, 14 Jan 2020 19:34:31 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailauth.nyi.internal (Postfix) with ESMTP id EE3A822374 for ; Tue, 14 Jan 2020 14:34:30 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute2.internal (MEProxy); Tue, 14 Jan 2020 14:34:30 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtddugdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdevohhlihhnucfotgevrggsvgdfuceotghmtggtrggsvges rghprggthhgvrdhorhhgqeenucffohhmrghinheprghprggthhgvrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpegtmhgttggrsggvfedugedomhgvshhmthhprghuthhhphgv rhhsohhnrghlihhthidqgeeiudekgedufedtqdduheehkeekhedugedqtghmtggtrggsvg eppegrphgrtghhvgdrohhrghesfhgrshhtmhgrihhlrdgtohhmnecuvehluhhsthgvrhfu ihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C2880C200A4; Tue, 14 Jan 2020 14:34:30 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-754-g09d1619-fmstable-20200113v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 14 Jan 2020 11:33:00 -0800 From: "Colin McCabe" To: dev@kafka.apache.org Subject: =?UTF-8?Q?Re:_[DISCUSS]_KIP-546:_Add_quota-specific_APIs_to_the_Admin_Cl?= =?UTF-8?Q?ient,_redux?= Content-Type: text/plain 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 clients IDs. This is probably a nitpick, but it would be nice to specify that this list is in order of highest priority to lowest. > --include-overrides: Whether to include overridden config entries. Hmm. Maybe --show-overridden or --include-overridden is a better flag name? I think it would be nice to avoid using enums for QuotaEntity#Type, QuotaKey#Type, and QuotaFilter#Rule. With enums, we have to worry about forwards and backwards compatibility problems. For example, what do you do when you're querying a broker that has a new value for one of these, that is not in your enum? In the past, we've created an UNKNOWN value for enum types to solve this conundrum, but I'm not sure the extra complexity is worth it here. We can jut make them strings and avoid worrying about the compatibility issues. Is QuotaKey#Units really needed? It seems like perhaps QuotaKey#Type could imply the units used. > public DescribeQuotasResult(KafkaFuture>> entities); How common is the prefix matching use-case? I haven't heard about people setting up principal names with a common prefix or anything like that-- is that commonly done? I sort of feel like maybe we could have a simpler API for describeQuotas where it takes a map of quota entity type to value, and we do a logical AND On that. I'm not sure if there's really a reason why it needs to be a collection rather than a set, in other words... cheers, Colin On Wed, Dec 11, 2019, at 15:30, Brian Byrne wrote: > 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" on quotas, > among other minor updates. > > Please take a look, and I'll be happy to make any clarifications and > modifications in regards to feedback. > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-546%3A+Add+quota-specific+APIs+to+the+Admin+Client%2C+redux > > Thanks, > Brian >