Implement list_topics, describe_topics, and describe_cluster #1993
Conversation
| def describe_cluster(self): | ||
| metadata = self._get_cluster_metadata() | ||
| obj = metadata.to_object() | ||
| obj.pop('topics') # We have 'describe_topics' for this |
There was a problem hiding this comment.
Does the Java client include or exclude the topics as part of the cluster metadata call?
I know it seems redundant but dropping them here forces the caller to issue two API calls to the Kafka broker if they want both... not ideal for monitoring scripts that may run frequently. Although I suppose if someone really cares they can call _get_cluster_metadata() directly.
But really I just think we should follow the Java client here, so if they drop the topics, then we should too...
There was a problem hiding this comment.
Yeah, based on their javadoc they exclude topics as part of the metadata call, though it also looks like they avoid fetching the topics at all.
It's easy enough to throw in a def describe_cluster_and_topics if you want to deviate from the java client a bit?
There was a problem hiding this comment.
Let's leave as-is if it follows Java, that will be good enough for now and anyone who wants the speed boost can live dangerously with _get_cluster_metadata().
Also, my reading of that Java code is they're passing an empty list for the topics, which maps to fetching all topics... but I could be wrong it's been over a year since I looked at the Metadata protocol definition.
There was a problem hiding this comment.
It's been a bit for myself as well, I'm testing it now. I also just noticed that I had missed the "use controller for describe topics" comment, I'm adding that now
There was a problem hiding this comment.
Oh right, I missed that too!
There was a problem hiding this comment.
FTR this was fixed in #1995
|
Thanks again for this! |
This is just #1956 but with a clean commit history
This change is