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 prop
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 fields
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 a
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, an
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 repl
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
On
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 o
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
Admin.
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 n
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 mat
Hi Travis and thanks for the KIP, two comments below:
Den fre 11 nov. 2022 kl 13:37 skrev David Jacot :
> 02: I am a bit concerned by clients that could misuse these information.
> For instance, one may be tempted to rely on the version to decide whether a
> feature is enabled or not. The api ve
Hi Travis,
Thanks for the KIP. That seems to be a useful addition. I have a few
concerns/comments:
01: Managed Kafka services do not necessarily run a specific version or may
not want to expose it. I suppose that they could keep an empty string.
02: I am a bit concerned by clients that could mis
Hi all,
I've written a KIP to expose the BrokerSoftwareName and
BrokerSoftwareVersion to clients:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-885%3A+Expose+Broker%27s+Name+and+Version+to+Clients
If we agree this is useful, it would be great to have this in by 3.4.
Thank you,
- Travis
13 matches
Mail list logo
