Pinging on this, to refresh any inboxes.
On 2023/01/01 20:16:18 Travis Bischel wrote:
> To confirm, you’re now thinking that we should add name + version to every
> broker in the response? AFAICT, this grows the complexity of implementation a
> good amount. The implementation of the current
To confirm, you’re now thinking that we should add name + version to every
broker in the response? AFAICT, this grows the complexity of implementation a
good amount. The implementation of the current proposal is just to add a
configuration option and put it in the new string. Adding these
05/06. I also find BrokerSoftwareName and BrokerSoftwareVersion odd to
be honest because the RPC is supposed to describe the cluster. I was
also re-considering adding it per broker but this would be a little
more involved. It basically requires every broker to send their
version to the controller
Thanks for the reply,
04. `nullable-string`, my mistake on that — this is the representation I have
for nullable strings in my own DSL in franz-go. I’ve fixed that.
05. I think that ClusterSoftwareVersion and ClusterSoftwareName would be a bit
odd: technically these are per-broker responses,
Yeah, it is too late for 3.4. I have a few more comments:
04. `nullable-string` is not a valid type. You have to use "type":
"string", "versions": "1+", "nullableVersions": "1+".
05. BrokerSoftwareName/BrokerSoftwareVersion feel a bit weird in a
DescribeClusterResponse. I wonder if we should
I see now that this KIP is past the freeze deadline and will not make 3.4 —
but, 3.4 thankfully will still be able to be detected by an ApiVersions
response due to KIP-866. I’d like to proceed with this KIP to ensure full
implementation can be agreed upon and merged by 3.5.
Thanks!
- Travis
Hi David,
No worries for the late reply — my main worry is getting this in by Kafka 3.4
so there is no gap in detecting versions :)
I’m +1 to adding this to DescribeCluster. I just edited the KIP to replace
ApiVersions with DescribeCluster, and added the original ApiVersions idea to
the list
Hi Travis,
Please, excuse me for my late reply.
02. Yeah, I agree that it is more convenient to rely on the api
versions but that does not protect us from misuages.
03. Yeah, I was about to suggest the same. Adding the information to
the DescribeCluster API would work and we also have the
Two quick mistakes to clarify:
When I say ClusterMetadata, I mean request 60, DescribeCluster.
Also, the email subject of this entire thread should be "[DISCUSS] KIP-885:
Expose Broker's Name and Version to Clients”. I must have either accidentally
pasted the “Skip to end of metadata”, or did
Thanks for the replies David and Magnus
David:
02: From a client implementation perspective, it is easier to gate features
based on the max version numbers returned per request, rather than any textual
representation of a string. I’m not really envisioning a client implementation
trying to
10 matches
Mail list logo
