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 >
