Cool, that makes sense. Guozhang
On Mon, May 4, 2020 at 2:50 PM Colin McCabe <cmcc...@apache.org> wrote: > I think once something becomes more complex than just key = value it's > time to consider an official Kafka API, rather than trying to fit it into > AlterConfigs. For example, for client quotas, we have KIP-546. > > There are just so many reasons. Real Kafka APIs have well-defined > compatibility policies, Java types defined that make them easy to use, and > APIs that can return partial results rather than needing to do the > filtering on the client side. > > best, > Colin > > > On Mon, May 4, 2020, at 14:30, Guozhang Wang wrote: > > Got it. > > > > Besides SCRAM, are there other scenarios that we may have such > > "hierarchical" (I know the term may not be very accurate here :P) configs > > such as "config1=[key1=value1, key2=value2]" compared with most common > > pattern of "config1=value1" or "config1=value1,config2=value2"? For > example > > I know that quotas may be specified in the former pattern as well. If we > > believe that such hierarchical configuration may be more common in the > > future, I'm wondering should we just consider support it more natively in > > alter/describe config patterns. > > > > > > Guozhang > > > > > > On Mon, May 4, 2020 at 1:32 PM Colin McCabe <cmcc...@apache.org> wrote: > > > > > If we use AlterConfigs then we end up parsing strings like > > > > 'SCRAM-SHA-256=[iterations=8192,password=alice-secret],SCRAM-SHA-512=[password=alice-secret]' > > > on the broker into the same information that's currently in > > > ScramUserAlteration. This doesn't change the complexity of the > > > command-line tool, since it does that parsing anyway. But it does mean > > > that other programs that wanted to interact with SCRAM via the API > would > > > not really have datatypes to describe what they were doing, just lumps > of > > > text. > > > > > > Another question is how would we even list SCRAM users if we were to > > > re-purpose AlterConfigs / DescribeConfigs for this. I suppose if we > wanted > > > to go down this path we could define a new resource and use > DescribeConfigs > > > to describe its keys. But its values would always have to be returned > as > > > null by DescribeConfigs, since they would be considered "sensitive." > > > > > > best, > > > Colin > > > > > > > > > On Sun, May 3, 2020, at 17:30, Guozhang Wang wrote: > > > > Hello Colin, > > > > > > > > Thanks for the KIP. The proposal itself looks good to me; but could > you > > > > elaborate a bit more on the rejected alternative of reusing > > > > IncrementalAlterConfigs? What do you mean by complex string > manipulation, > > > > as well as error conditions? > > > > > > > > Guozhang > > > > > > > > > > > > On Fri, May 1, 2020 at 5:12 PM Colin McCabe <cmcc...@apache.org> > wrote: > > > > > > > > > On Fri, May 1, 2020, at 08:35, Aneel Nazareth wrote: > > > > > > Hi Colin, > > > > > > > > > > > > Thanks for the KIP. Is it also in scope to add support for the > new > > > API > > > > > > to the Admin interface and the implementation in > KafkaAdminClient? > > > > > > > > > > > > > > > > Hi Aneel, > > > > > > > > > > Yes, we will have a Java API. The new Admin API is described in > the > > > KIP. > > > > > > > > > > best, > > > > > Colin > > > > > > > > > > > > > > > > On Fri, May 1, 2020 at 1:18 AM Colin McCabe <cmcc...@apache.org> > > > wrote: > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I posted a KIP about adding a new SCRAM configuration API on > the > > > > > broker. Check it out here if you get a chance: > > > > > https://cwiki.apache.org/confluence/x/ihERCQ > > > > > > > > > > > > > > cheers, > > > > > > > Colin > > > > > > > > > > > > > > > > > > > > > > > -- > > > > -- Guozhang > > > > > > > > > > > > > -- > > -- Guozhang > > > -- -- Guozhang
