Hello Colin, Rajini and Jun, I have updated the KIP 422, please take another look!
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=97555704 Thanks! Yaodong On Tue, May 7, 2019 at 11:54 AM Yaodong Yang <yangyaodon...@gmail.com> wrote: > Hello Colin, Rajini and Jun, > > I think it makes sense to have new APIs defined in the AdminClient for > quota management only, as Colin described above. For the request and > response protocol, It seems like we can leverage the existing requests: > *IncrementalAlterConfigsRequest* and *DescribeConfigsRequest*. In this > way, we convert the quota management requests (set quota, describe quota > and delete quotas) to configuration changes for User resource and Client > resource (e.g. update a configuration to user 1 ). And then we send the > configuration change request to the broker side. Therefore, we will not > have any protocol changes for this KIP. > > Please let me know what you think. > > Thanks! > Yaodong > > > On Mon, Apr 15, 2019 at 12:16 PM Colin McCabe <cmcc...@apache.org> wrote: > >> Hi all, >> >> In KIP-133: Describe and Alter Configs Admin APIs, there is "future work" >> section that explains: >> >> > Future Work >> > ... >> > >> > 2. Support for reading and updating client, user and replication >> quotas. We >> > initially included that in the KIP, but it subsequently became >> apparent >> > that a separate protocol and AdminClient API would be more >> appropriate. >> > The reason is that client/user quotas can be applied on a client id, >> user >> > or (client id, user) tuple. In the future, the hierarchy may get even >> more >> > complicated. So, it makes sense to keeping the API simple for the >> simple >> > cases while introducing a more sophisticated API for the more complex >> case. >> >> In other words, we deliberately didn't implement quotas through >> AlterConfigs because we felt like it the AlterConfigs API wasn't really >> complex enough to handle quotas well. >> >> I think that the original discussion was correct here -- we should have a >> special API for quotas, rather than trying to shoehorn them into the >> AlterConfigs API. >> >> For example, we could have an API like this: >> >> > >> > SetQuotasResults setQuotas(Map<QuotaTarget, QuotaLimit> quotas, >> SetQuotasOptions options) >> > >> > interface QuotaTarget { >> > } >> > >> > class ClientQuotaTarget implements QuotaTarget { >> > String clientId; >> > } >> > >> > class PrincipalQuotaTarget implements QuotaTarget { >> > String principal; >> > } >> > >> > class ClientAndPrincipalQuotaTarget implements QuotaTarget { >> > String clientId; >> > String principal; >> > } >> > >> > class QuotaLimit { >> > long bytesWrittenPerSec; >> > long bytesReadPerSec; >> > } >> > >> > DescribeQuotasResults describeQuotas(QuotaTarget target, >> DescribeQuotasOptions options); >> > >> > ListQuotasResults listQuotas(ListQuotasOptions options); >> > >> >> This would avoid the need to parse text strings. It would also make it >> really clear how to use and extend the API. >> >> best, >> Colin >> >> On Mon, Apr 8, 2019, at 05:29, Rajini Sivaram wrote: >> > Hi Jun, Yaodong, >> > >> > 21. The proposed approach sounds very hacky. User principals can contain >> > arbitrary characters. So we can't simply split `user1/clients/clientA` >> into >> > tokens using '/' as delimiter. Internally, we sanitize names before >> > storing in ZK, but the names provided by the user are actual principals >> and >> > client-ids. I think we want to have entity names that explicitly specify >> > (type, name) as in the CLI kafka-configs.sh and allow multiple entities >> to >> > be specified together for (user, client-id). That will also enable us to >> > configure defaults in a consistent way. >> > >> > 22. Yes, that sounds reasonable. >> > >> > On Fri, Apr 5, 2019 at 11:13 PM Jun Rao <j...@confluent.io> wrote: >> > >> > > Hi, Yaodong, >> > > >> > > Yes, what you proposed makes sense. A couple of more comments. >> > > >> > > 21. Could you add those examples to the KIP wiki? It would also be >> useful >> > > to know how to set the ConfigEntry value for quotas at >> > > DefaultClientInUser, DefaultClientDefaultUser and DefaultUser level. >> > > >> > > 22. To support KIP-257, I guess we can just pass in some special >> string >> > > value in ConfigEntry value through alterConfig and let the customized >> > > implementation of ClientQuotaCallback parse it. It would be useful to >> > > document this. Does that sound reasonable, Rajini? >> > > >> > > Thanks, >> > > >> > > Jun >> > > >> > > On Fri, Apr 5, 2019 at 2:03 PM Yaodong Yang <yangyaodon...@gmail.com> >> > > wrote: >> > > >> > >> Hi Jun, >> > >> >> > >> The proposal we have right now is to directly set the quota through >> > >> existing admin client APIs. See following examples: >> > >> >> > >> Example 1: set a user quota >> > >> >> > >> AdminClient adminClient = mock(AdminClient.class); >> > >> Map<ConfigResource, Config> configs = new HashMap(); >> > >> Config config = new Config(Arrays.asList(new ConfigEntry("user1", >> > >> "producer_byte_rate=1024"))); >> > >> configs.put(singletonMap(ConfigResource.USER, config)); >> > >> adminClient.alterConfigs(configs); >> > >> >> > >> >> > >> Example 2: set a client id quota >> > >> >> > >> AdminClient adminClient = mock(AdminClient.class); >> > >> Map<ConfigResource, Config> configs = new HashMap(); >> > >> Config config = new Config(Arrays.asList(new ConfigEntry("client1", >> > >> "producer_byte_rate=1024"))); >> > >> configs.put(singletonMap(ConfigResource.CLIENT, config)); >> > >> adminClient.alterConfigs(configs); >> > >> >> > >> >> > >> Example 3: set a <user, client-id> quota >> > >> >> > >> AdminClient adminClient = mock(AdminClient.class); >> > >> Map<ConfigResource, Config> configs = new HashMap(); >> > >> Config config = new Config(Arrays.asList(new >> > >> ConfigEntry("user1/clients/client2", "producer_byte_rate=1024"))); >> > >> configs.put(singletonMap(ConfigResource.USER, config)); >> > >> adminClient.alterConfigs(configs); >> > >> >> > >> >> > >> The current KIP is orthogonal to KIP 257. It only adds a new way to >> store >> > >> the quotas in ZK through AdminClient. For customizable quotas, they >> will >> > >> also be a property in User resources or Client resources. >> > >> >> > >> Quote from *CustomQuotaCallbackTest.scala::GroupedUserQuotaCallback* >> in >> > >> the >> > >> codebase, “Group quotas are configured in ZooKeeper as user quotas >> with >> > >> the >> > >> entity name "${group}_". Default group quotas are configured in >> ZooKeeper >> > >> as user quotas with the entity name "_".” >> > >> In this example, they are always stored as properties in the User >> > >> resource, >> > >> the property name is “$(group)_” and “_”. The client application >> needs to >> > >> encode them correctly before store them in ZK through AdminClient, >> while >> > >> the customizedCallback needs to decode them and apply during the >> process >> > >> of >> > >> each request. >> > >> >> > >> The advantage of the current KIP is simple and extensible for the >> future >> > >> release. The alternative is to introduce a new set of quota related >> APIs >> > >> in >> > >> the AdminClient, similar to the ACL related. I'm not sure which one >> people >> > >> prefer. >> > >> >> > >> Thanks! >> > >> Yaodong >> > >> >> > >> On Wed, Mar 13, 2019 at 6:29 PM Jun Rao <j...@confluent.io> wrote: >> > >> >> > >> > Hi, Yaodong, >> > >> > >> > >> > Thanks for the updated KIP. A few more comments below. >> > >> > >> > >> > 11. For quotas, in addition to user and client, we need to be able >> to >> > >> set a >> > >> > quota for <client, user> combination. Would that be a new resource >> type? >> > >> > How would the name look like for this resource? >> > >> > >> > >> git chec >> > >> >> > >> > >> > >> > 12. Similarly, to support customizable quota ( >> > >> > >> > >> > >> > >> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-257+-+Configurable+Quota+Management >> > >> > ), >> > >> > do we need a new resource type? What would the name of the resource >> > >> looks >> > >> > like? >> > >> > >> > >> > 13. You only listed 2 new ConfigSource. Could you list all the new >> ones? >> > >> > For example, >> > >> > >> > >> > >> > >> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-248+-+Create+New+ConfigCommand+That+Uses+The+New+AdminClient >> > >> > listed a few others such as ClientInUser, DefaultClientInUser. >> > >> > >> > >> > 14. Could you list any new ACL that might be required? For >> example, what >> > >> > types of operations are allowed for the new Resource (User, Client, >> > >> etc)? >> > >> > What are the permissions needed for the new operations? >> > >> > >> > >> > 15. Could you give a few examples on how to use the new API? >> > >> > >> > >> > Thanks, >> > >> > >> > >> > Jun >> > >> > >> > >> > On Tue, Mar 12, 2019 at 9:56 AM Yaodong Yang < >> yangyaodon...@gmail.com> >> > >> > wrote: >> > >> > >> > >> > > ping... >> > >> > > >> > >> > > On Thu, Feb 28, 2019 at 10:23 AM Yaodong Yang < >> > >> yangyaodon...@gmail.com> >> > >> > > wrote: >> > >> > > >> > >> > >> Hello folks, >> > >> > >> >> > >> > >> Please share your comments for this KIP 😄 >> > >> > >> >> > >> > >> Thanks! >> > >> > >> Yaodong >> > >> > >> >> > >> > >> On Tue, Feb 26, 2019 at 6:53 PM Yaodong Yang < >> > >> yangyaodon...@gmail.com> >> > >> > >> wrote: >> > >> > >> >> > >> > >>> Hello Colin, >> > >> > >>> >> > >> > >>> There is a POC PR for this KIP, and it contains most changes >> we are >> > >> > >>> proposing now. >> > >> > >>> >> > >> > >>> Best, >> > >> > >>> Yaodong >> > >> > >>> >> > >> > >>> On Tue, Feb 26, 2019 at 6:51 PM Yaodong Yang < >> > >> yangyaodon...@gmail.com> >> > >> > >>> wrote: >> > >> > >>> >> > >> > >>>> Hello Colin, >> > >> > >>>> >> > >> > >>>> CIL, >> > >> > >>>> >> > >> > >>>> Thanks! >> > >> > >>>> Yaodong >> > >> > >>>> >> > >> > >>>> >> > >> > >>>> On Tue, Feb 26, 2019 at 9:59 AM Colin McCabe < >> cmcc...@apache.org> >> > >> > >>>> wrote: >> > >> > >>>> >> > >> > >>>>> Hi Yaodong, >> > >> > >>>>> >> > >> > >>>>> I don't understand how the proposed API would be used. It >> talks >> > >> > about >> > >> > >>>>> adding a ConfigResource type for clients and users, but >> doesn't >> > >> > explain >> > >> > >>>>> what can be done with these. >> > >> > >>>>> >> > >> > >>>> >> > >> > >>>> Sorry for the confusion. I just updated the KIP, and >> hopefully it >> > >> will >> > >> > >>>> make it easier for you and other people. Looking forward to >> your >> > >> > feedback! >> > >> > >>>> >> > >> > >>>> >> > >> > >>>>> In the compatibility section (?) it says "We only add a new >> way to >> > >> > >>>>> configure the quotas" which suggests that quotas are involved >> > >> > somehow What >> > >> > >>>>> relationship does this have with KIP-257? >> > >> > >>>>> >> > >> > >>>> >> > >> > >>>> Let me give you more context, feel free to correct me if I'm >> wrong >> > >> 😁 >> > >> > >>>> >> > >> > >>>> 1. Originally we hit an issue that we can not config client >> quota >> > >> > >>>> through AdminClient. The only way available for us is >> directly talk >> > >> > to ZK >> > >> > >>>> and manage quota directly. >> > >> > >>>> >> > >> > >>>> 2. As our client service may not in the same DC as ZooKeeper, >> there >> > >> > >>>> could be some cross DC communication which is less desirable. >> > >> > >>>> >> > >> > >>>> 3. We deicide to add the quota configuration feature in the >> > >> > >>>> AdminClient, which will perfectly solve this issue for us. >> > >> > >>>> >> > >> > >>>> 4. In addition, we realized that this change can also serve >> as a >> > >> way >> > >> > to >> > >> > >>>> config other users or clients configuration in Zookeeper. For >> > >> > instance, if >> > >> > >>>> we have a new client configuration introduced in the future >> and >> > >> they >> > >> > need >> > >> > >>>> to be in the Zookeeper as well, we can mange it through the >> same >> > >> API. >> > >> > >>>> Therefore, this KIP is renamed to manage users/clients >> > >> configurations. >> > >> > >>>> Quota management is one use case for this configuration >> management. >> > >> > >>>> >> > >> > >>>> 5. KIP-257 is also compatible with the current KIP. For >> instance, >> > >> if >> > >> > >>>> user want to update a quota for a metric, the client side >> need to >> > >> > parse it, >> > >> > >>>> and eventually pass in a user or client config to AdminClient. >> > >> > AdminClient >> > >> > >>>> will make sure such configuration changes are applied in the >> > >> > Zookeeper. >> > >> > >>>> >> > >> > >>>> >> > >> > >>>>> best, >> > >> > >>>>> Colin >> > >> > >>>>> >> > >> > >>>>> >> > >> > >>>>> On Fri, Feb 22, 2019, at 15:11, Yaodong Yang wrote: >> > >> > >>>>> > Hi Colin, >> > >> > >>>>> > >> > >> > >>>>> > CIL, >> > >> > >>>>> > >> > >> > >>>>> > Thanks! >> > >> > >>>>> > Yaodong >> > >> > >>>>> > >> > >> > >>>>> > >> > >> > >>>>> > On Fri, Feb 22, 2019 at 10:56 AM Colin McCabe < >> > >> cmcc...@apache.org> >> > >> > >>>>> wrote: >> > >> > >>>>> > >> > >> > >>>>> > > Hi Yaodong, >> > >> > >>>>> > > >> > >> > >>>>> > > KIP-422 says that it would be good if "applications >> [could] >> > >> > >>>>> leverage the >> > >> > >>>>> > > unified KafkaAdminClient to manage their user/client >> > >> > >>>>> configurations, >> > >> > >>>>> > > instead of the direct dependency on Zookeeper." But the >> KIP >> > >> > >>>>> doesn't talk >> > >> > >>>>> > > about any changes to KafkaAdminClient. Instead, the only >> > >> changes >> > >> > >>>>> proposed >> > >> > >>>>> > > are to AdminZKClient. But that is an internal class-- >> we >> > >> don't >> > >> > >>>>> need a KIP >> > >> > >>>>> > > to change it, and it's not a public API that users can >> use. >> > >> > >>>>> > > >> > >> > >>>>> > >> > >> > >>>>> > Sorry for the confusion in the KIP. Actually there is no >> change >> > >> to >> > >> > >>>>> > AdminZKClient needed for this KIP, we just leverage them to >> > >> > >>>>> configure the >> > >> > >>>>> > properties in the ZK. You can find the details from this PR >> > >> > >>>>> > https://github.com/apache/kafka/pull/6189 >> > >> > >>>>> > >> > >> > >>>>> > As you can see from the PR, we need the client side and >> server >> > >> > >>>>> process >> > >> > >>>>> > changes, so I feel like we still need the KIP for this >> change. >> > >> > >>>>> > >> > >> > >>>>> > >> > >> > >>>>> > > I realize that the naming might be a bit confusing, but >> > >> > >>>>> > > kafka.zk.AdminZKClient and kafka.admin.AdminClient are >> > >> internal >> > >> > >>>>> classes. >> > >> > >>>>> > > As the JavaDoc says, kafka.admin.AdminClient is >> deprecated as >> > >> > >>>>> well. The >> > >> > >>>>> > > public class that we would be adding new methods to is >> > >> > >>>>> > > org.apache.kafka.clients.admin.AdminClient. >> > >> > >>>>> > > >> > >> > >>>>> > >> > >> > >>>>> > I agree. Thanks for pointing this out! >> > >> > >>>>> > >> > >> > >>>>> > >> > >> > >>>>> > > best, >> > >> > >>>>> > > Colin >> > >> > >>>>> > > >> > >> > >>>>> > > On Tue, Feb 19, 2019, at 15:21, Yaodong Yang wrote: >> > >> > >>>>> > > > Hello Jun, Viktor, Snoke and Stan, >> > >> > >>>>> > > > >> > >> > >>>>> > > > Thanks for taking time to look at this KIP-422! For >> some >> > >> > reason, >> > >> > >>>>> this >> > >> > >>>>> > > email >> > >> > >>>>> > > > was put in my spam folder. Sorry about that. >> > >> > >>>>> > > > >> > >> > >>>>> > > > Jun is right, the main motivation for this KIP-422 is >> to >> > >> allow >> > >> > >>>>> users to >> > >> > >>>>> > > > config user/clientId quota through AdminClient. In >> addition, >> > >> > >>>>> this KIP-422 >> > >> > >>>>> > > > also allows users to set or update any config related >> to a >> > >> user >> > >> > >>>>> or >> > >> > >>>>> > > clientId >> > >> > >>>>> > > > entity if needed in the future. >> > >> > >>>>> > > > >> > >> > >>>>> > > > For the KIP-257, I agree with Jun that we should add >> support >> > >> > for >> > >> > >>>>> it. I >> > >> > >>>>> > > will >> > >> > >>>>> > > > look at the current implementation and update the >> KIP-422 >> > >> with >> > >> > >>>>> new >> > >> > >>>>> > > change. >> > >> > >>>>> > > > >> > >> > >>>>> > > > I will ping this thread once I updated the KIP. >> > >> > >>>>> > > > >> > >> > >>>>> > > > Thanks again! >> > >> > >>>>> > > > Yaodong >> > >> > >>>>> > > > >> > >> > >>>>> > > > On Fri, Feb 15, 2019 at 1:28 AM Viktor Somogyi-Vass < >> > >> > >>>>> > > viktorsomo...@gmail.com> >> > >> > >>>>> > > > wrote: >> > >> > >>>>> > > > >> > >> > >>>>> > > > > Hi Guys, >> > >> > >>>>> > > > > >> > >> > >>>>> > > > > I wanted to reject that KIP, split it up and revamp >> it as >> > >> in >> > >> > >>>>> the >> > >> > >>>>> > > meantime >> > >> > >>>>> > > > > there were some overlapping works I just didn't get >> to it >> > >> due >> > >> > >>>>> to other >> > >> > >>>>> > > > > higher priority work. >> > >> > >>>>> > > > > One of the splitted KIPs would have been the quota >> part of >> > >> > >>>>> that and >> > >> > >>>>> > > I'd be >> > >> > >>>>> > > > > happy if that lived in this KIP if Yaodong thinks >> it's >> > >> worth >> > >> > to >> > >> > >>>>> > > > > incorporate. I'd be also happy to rebase that wire >> > >> protocol >> > >> > and >> > >> > >>>>> > > contribute >> > >> > >>>>> > > > > it to this KIP. >> > >> > >>>>> > > > > >> > >> > >>>>> > > > > Viktor >> > >> > >>>>> > > > > >> > >> > >>>>> > > > > On Wed, Feb 13, 2019 at 7:14 PM Jun Rao < >> j...@confluent.io >> > >> > >> > >> > >>>>> wrote: >> > >> > >>>>> > > > > >> > >> > >>>>> > > > > > Hi, Yaodong, >> > >> > >>>>> > > > > > >> > >> > >>>>> > > > > > Thanks for the KIP. As Stan mentioned earlier, it >> seems >> > >> > that >> > >> > >>>>> this is >> > >> > >>>>> > > > > > mostly covered by KIP-248, which was originally >> > >> proposed by >> > >> > >>>>> Victor. >> > >> > >>>>> > > > > > >> > >> > >>>>> > > > > > Hi, Victor, >> > >> > >>>>> > > > > > >> > >> > >>>>> > > > > > Do you still plan to work on KIP-248? It seems >> that you >> > >> > >>>>> already got >> > >> > >>>>> > > > > pretty >> > >> > >>>>> > > > > > far on that. If not, would you mind letting >> Yaodong take >> > >> > >>>>> over this? >> > >> > >>>>> > > > > > >> > >> > >>>>> > > > > > For both KIP-248 and KIP-422, one thing that I >> found >> > >> > missing >> > >> > >>>>> is the >> > >> > >>>>> > > > > > support for customized quota ( >> > >> > >>>>> > > > > > >> > >> > >>>>> > > > > >> > >> > >>>>> > > >> > >> > >>>>> >> > >> > >> > >> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-257+-+Configurable+Quota+Management >> > >> > >>>>> > > > > ). >> > >> > >>>>> > > > > > With KIP-257, it's possible for one to construct a >> > >> > >>>>> customized quota >> > >> > >>>>> > > > > defined >> > >> > >>>>> > > > > > through a map of metric tags. It would be useful to >> > >> support >> > >> > >>>>> that in >> > >> > >>>>> > > the >> > >> > >>>>> > > > > > AdminClient API and the wire protocol. >> > >> > >>>>> > > > > > >> > >> > >>>>> > > > > > Hi, Sonke, >> > >> > >>>>> > > > > > >> > >> > >>>>> > > > > > I think the proposal is to support the >> user/clientId >> > >> level >> > >> > >>>>> quota >> > >> > >>>>> > > through >> > >> > >>>>> > > > > > an AdminClient api. The user can be obtained from >> any >> > >> > >>>>> existing >> > >> > >>>>> > > > > > authentication mechanisms. >> > >> > >>>>> > > > > > >> > >> > >>>>> > > > > > Thanks, >> > >> > >>>>> > > > > > >> > >> > >>>>> > > > > > Jun >> > >> > >>>>> > > > > > >> > >> > >>>>> > > > > > On Thu, Feb 7, 2019 at 5:59 AM Sönke Liebau >> > >> > >>>>> > > > > > <soenke.lie...@opencore.com.invalid> wrote: >> > >> > >>>>> > > > > > >> > >> > >>>>> > > > > >> Hi Yaodong, >> > >> > >>>>> > > > > >> >> > >> > >>>>> > > > > >> thanks for the KIP! >> > >> > >>>>> > > > > >> >> > >> > >>>>> > > > > >> If I understand your intentions correctly then >> this KIP >> > >> > >>>>> would only >> > >> > >>>>> > > > > >> address a fairly specific use case, namely >> SASL-PLAIN >> > >> with >> > >> > >>>>> users >> > >> > >>>>> > > > > >> defined in Zookeeper. For all other authentication >> > >> > >>>>> mechanisms like >> > >> > >>>>> > > > > >> SSL, SASL-GSSAPI or SASL-PLAIN with users defined >> in >> > >> jaas >> > >> > >>>>> files I >> > >> > >>>>> > > > > >> don't see how the AdminClient could directly >> create new >> > >> > >>>>> users. >> > >> > >>>>> > > > > >> Is this correct, or am I missing something? >> > >> > >>>>> > > > > >> >> > >> > >>>>> > > > > >> Best regards, >> > >> > >>>>> > > > > >> Sönke >> > >> > >>>>> > > > > >> >> > >> > >>>>> > > > > >> On Thu, Feb 7, 2019 at 2:47 PM Stanislav Kozlovski >> > >> > >>>>> > > > > >> <stanis...@confluent.io> wrote: >> > >> > >>>>> > > > > >> > >> > >> > >>>>> > > > > >> > This KIP seems to duplicate some of the >> functionality >> > >> > >>>>> proposed in >> > >> > >>>>> > > > > >> KIP-248 >> > >> > >>>>> > > > > >> > < >> > >> > >>>>> > > > > >> >> > >> > >>>>> > > > > >> > >> > >>>>> > > >> > >> > >>>>> >> > >> > >> > >> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-248+-+Create+New+ConfigCommand+That+Uses+The+New+AdminClient >> > >> > >>>>> > > > > >> >. >> > >> > >>>>> > > > > >> > KIP-248 has been stuck in a vote thread since >> July >> > >> 2018. >> > >> > >>>>> > > > > >> > >> > >> > >>>>> > > > > >> > Viktor, do you plan on working on the KIP? >> > >> > >>>>> > > > > >> > >> > >> > >>>>> > > > > >> > On Thu, Feb 7, 2019 at 1:27 PM Stanislav >> Kozlovski < >> > >> > >>>>> > > > > >> stanis...@confluent.io> >> > >> > >>>>> > > > > >> > wrote: >> > >> > >>>>> > > > > >> > >> > >> > >>>>> > > > > >> > > Hey there Yaodong, thanks for the KIP! >> > >> > >>>>> > > > > >> > > >> > >> > >>>>> > > > > >> > > I'm not too familiar with the user/client >> > >> > >>>>> configurations we >> > >> > >>>>> > > > > currently >> > >> > >>>>> > > > > >> > > allow, is there a KIP describing the initial >> > >> feature? >> > >> > >>>>> If there >> > >> > >>>>> > > is, >> > >> > >>>>> > > > > it >> > >> > >>>>> > > > > >> would >> > >> > >>>>> > > > > >> > > be useful to include in KIP-422. >> > >> > >>>>> > > > > >> > > >> > >> > >>>>> > > > > >> > > I also didn't see any authorization in the PR, >> > >> have we >> > >> > >>>>> thought >> > >> > >>>>> > > about >> > >> > >>>>> > > > > >> > > needing to authorize the alter/describe >> requests >> > >> per >> > >> > the >> > >> > >>>>> > > > > user/client? >> > >> > >>>>> > > > > >> > > >> > >> > >>>>> > > > > >> > > Thanks, >> > >> > >>>>> > > > > >> > > Stanislav >> > >> > >>>>> > > > > >> > > >> > >> > >>>>> > > > > >> > > On Fri, Jan 25, 2019 at 5:47 PM Yaodong Yang < >> > >> > >>>>> > > > > yangyaodon...@gmail.com >> > >> > >>>>> > > > > >> > >> > >> > >>>>> > > > > >> > > wrote: >> > >> > >>>>> > > > > >> > > >> > >> > >>>>> > > > > >> > >> Hi folks, >> > >> > >>>>> > > > > >> > >> >> > >> > >>>>> > > > > >> > >> I've published KIP-422 which is about adding >> > >> support >> > >> > >>>>> for >> > >> > >>>>> > > > > user/client >> > >> > >>>>> > > > > >> > >> configurations in the Kafka Admin Client. >> > >> > >>>>> > > > > >> > >> >> > >> > >>>>> > > > > >> > >> Basically the story here is to allow >> > >> KafkaAdminClient >> > >> > >>>>> to >> > >> > >>>>> > > configure >> > >> > >>>>> > > > > >> the >> > >> > >>>>> > > > > >> > >> user >> > >> > >>>>> > > > > >> > >> or client configurations for users, instead >> of >> > >> > >>>>> requiring users >> > >> > >>>>> > > to >> > >> > >>>>> > > > > >> directly >> > >> > >>>>> > > > > >> > >> talk to ZK. >> > >> > >>>>> > > > > >> > >> >> > >> > >>>>> > > > > >> > >> The link for this KIP is >> > >> > >>>>> > > > > >> > >> following: >> > >> > >>>>> > > > > >> > >> >> > >> > >>>>> > > > > >> >> > >> > >>>>> > > > > >> > >> > >>>>> > > >> > >> > >>>>> >> > >> > >> > >> >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=97555704 >> > >> > >>>>> > > > > >> > >> >> > >> > >>>>> > > > > >> > >> I'd be happy to receive some feedback about >> the >> > >> KIP I >> > >> > >>>>> > > published. >> > >> > >>>>> > > > > >> > >> >> > >> > >>>>> > > > > >> > >> -- >> > >> > >>>>> > > > > >> > >> Best, >> > >> > >>>>> > > > > >> > >> Yaodong Yang >> > >> > >>>>> > > > > >> > >> >> > >> > >>>>> > > > > >> > > >> > >> > >>>>> > > > > >> > > >> > >> > >>>>> > > > > >> > > -- >> > >> > >>>>> > > > > >> > > Best, >> > >> > >>>>> > > > > >> > > Stanislav >> > >> > >>>>> > > > > >> > > >> > >> > >>>>> > > > > >> > >> > >> > >>>>> > > > > >> > >> > >> > >>>>> > > > > >> > -- >> > >> > >>>>> > > > > >> > Best, >> > >> > >>>>> > > > > >> > Stanislav >> > >> > >>>>> > > > > >> >> > >> > >>>>> > > > > >> >> > >> > >>>>> > > > > >> >> > >> > >>>>> > > > > >> -- >> > >> > >>>>> > > > > >> Sönke Liebau >> > >> > >>>>> > > > > >> Partner >> > >> > >>>>> > > > > >> Tel. +49 179 7940878 >> > >> > >>>>> > > > > >> OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - >> 22880 >> > >> > Wedel >> > >> > >>>>> - >> > >> > >>>>> > > Germany >> > >> > >>>>> > > > > >> >> > >> > >>>>> > > > > > >> > >> > >>>>> > > > > >> > >> > >>>>> > > > >> > >> > >>>>> > > >> > >> > >>>>> > >> > >> > >>>>> >> > >> > >>>> >> > >> > >> > >> >> > > >> > >> >
