Thanks Colin for the inputs. Regarding *I think most users of the DescribeConfigs API do not want to get help text or configuration schema information. * There is already a precedence of including this information as part of Connect Config - both type and documentation - and we have found it quite useful in the Config client forms.
*It would be better to create a new, separate API for getting this configuration schema information, if that's what we really want. This API should probably also allow configuration management systems to list all the possible configurations for topics, brokers, etc., which is something that I think many of them would want.> * Correct. I believe AdminClient.describeConfig already provides us that today. From the docs - "Get the configuration for the specified resources with the default options." This api gives us back all the configuration information for the specified resources(s) - broker or topic. *We also need to consider compatibility. One example is, what if we later add a new type of configuration key, such as UUID. What would the hypothetical DescribeConfigurationSchema API return in this case, for older clients? We probably need an UNKNOWN enum value to be used to indicate that the server knows about configuration key types that the client does not.> * I believe we already handle backward compatibility via versioning on the message schema. For example 'Synonyms' is only available from 1+ version and treated nullable for previous ones. The expectation with the new fields is similar. Thanks Shailesh On 2020/02/26 22:17:39, "Colin McCabe" <c...@apache.org> wrote: > Hi Shailesh,> > > I think most users of the DescribeConfigs API do not want to get help text or configuration schema information. So, it would be inefficient to always include this information as part of the DescribeConfigs response. It would be better to create a new, separate API for getting this configuration schema information, if that's what we really want. This API should probably also allow configuration management systems to list all the possible configurations for topics, brokers, etc., which is something that I think many of them would want.> > > We also need to consider compatibility. One example is, what if we later add a new type of configuration key, such as UUID. What would the hypothetical DescribeConfigurationSchema API return in this case, for older clients? We probably need an UNKNOWN enum value to be used to indicate that the server knows about configuration key types that the client does not.> > > best,> > Colin> > > > On Wed, Feb 19, 2020, at 09:13, Shailesh Panwar wrote:> > > Bump.> > > > > > Thanks> > > Shailesh> > > > > > On Tue, Feb 11, 2020 at 1:00 PM Shailesh Panwar <sp...@confluent.io>> > > wrote:> > > > > > > Hi all,> > > > We would like to extend the DescribeConfigsResponse schema to include the> > > > data-type of the fields.> > > >> > > > The KIP can be found here:> > > >> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-569%3A+DescribeConfigsResponse+-+Update+the+schema+to+include+datatype+of+the+field> > > >> > > > Thanks> > > > Shailesh> > > >> > >> >
