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 >
