Hi all,
Thank you for your feedback. I have updated the KIP to incorporate it. I
have
changed the following:
* Added a few ideas in the future work section about metadata which could be
added in the future. This strengthens the motivation of the KIP.
* Added a section about the Metadata API to
Thanks for the KIP. I agree with keeping it simple in the first iteration.
If we can include the authorized operations clean-up without too much
effort, that would be great. But if it increases the scope a lot, I'd punt
it to the future.
Ismael
On Mon, Dec 14, 2020 at 8:10 AM David Jacot wrote:
On Fri, Dec 18, 2020, 12:48 PM Colin McCabe wrote:
> On Fri, Dec 18, 2020, at 08:32, Gwen Shapira wrote:
> > Agree. Once we have the basic API we can decide what belongs and what
> > doesn't. I remember requests for broker status, version, and various
> > other things. Considering all those
On Fri, Dec 18, 2020, at 08:32, Gwen Shapira wrote:
> Agree. Once we have the basic API we can decide what belongs and what
> doesn't. I remember requests for broker status, version, and various
> other things. Considering all those options together will be too much
> at this point.
>
Hi Gwen,
Agree. Once we have the basic API we can decide what belongs and what
doesn't. I remember requests for broker status, version, and various
other things. Considering all those options together will be too much
at this point.
One thing that may be worth considering is whether you want to include
Hi Colin,
Thanks for your feedback.
That is correct. I mention this in the future work section. I thought that
we
could remove it when we could also remove TopicAuthorizedOperations
in order to remain consistent in the API. We can also do it immediately.
I don't have a strong preference for any
Hi Ryan,
Thanks for your feedback. That's an interesting idea but that raises more
questions. At the moment, `describeCluster` only requires to be
authenticated
(if authentication is enabled) to get the basic information about the
cluster.
If we add the JMX port, is it something that we would
Hi David,
This seems reasonable. It would be nice to have an API specifically for
describeCluster, so that we could extend this API without adding more fields to
the already large MetadataRequest.
As you mention in the KIP, KIP-700 would allow us to deprecate
> I'd like to propose a small KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-700%3A+Add+Describe+Cluste
r+API
Hi David,
Since this is a new API, would it be possible to include each broker's JMX port
in the response? That's currently not part of the metadata API and it would
have
