Hi Sophie and Bruno, Thanks for the questions and suggestions. Not sure if it's best to discuss this in the DISCUSSION thread, but I will write it here first, and if it needs more discussion, we can move to the DISCUSSION thread. Actually, in the implementation, I have a version field in the ClientTag struct. I assumed that all structs must-have versions, and it's an explicit requirement; therefore, I left it out of KIP (fixed). I'm okay with changing the name to "rack.aware.assignment.tags" (fixed). As for upgrade and evolving tags, good question, we must try to make it as flexible as possible. Good catch that with encoding changing the tags may be problematic, especially changing the tags' order. One other way around it maybe is to change the "rack.aware.assignment.tags" config in a way that users can specify the tag index. For instance: rack.aware.assignment.tags.0: cluster, rack.aware.assignment.1: zone; But configuration is way uglier and more complicated (and easier to get wrong). Limiting the tag length and total amount of tags specified are already part of the implementation I work on. Assuming that encoding a limited number of strings is acceptable, I think it's the most straightforward way to move forward. Any objections? I've updated KIP [1] with the latest discussion points and reverted the "encoding tag keys" part (sorry Guozhang, I haven't really thought about this potential edge-case, and thanks, Sophie, for catching it).
I am looking forward to your feedback. Best, Levani [1] - https://cwiki.apache.org/confluence/display/KAFKA/KIP-708%3A+Rack+awareness+for+Kafka+Streams > On 16. Mar 2021, at 23:30, Bruno Cadonna <br...@confluent.io.INVALID> wrote: > > Sophie
