[
https://issues.apache.org/jira/browse/KAFKA-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16916881#comment-16916881
]
Vinoth Chandar commented on KAFKA-8810:
---------------------------------------
Great points [~vvcephei] . I have not considered EOS aspects. On rolling
upgrades, I was wondering if we could special case based on the "generation
number" (think this info is at the consumer level though) and the signature
hash.
Reflecting more, I think loosening this to enforcing compatibility is better,
as described in KAFKA-8307. During a rolling upgrade, if the necessary
information for compatibility checking is sent over to the leader instance,
then it can prevent an incompatible instance from joining the group again and
the its load would shift to other compatible instances.. We need some
compatibility check protocol (much like version_probing). Is this in the scope
of 8307?
[~pkleindl] I like the idea of a topology registry. I think it will bring some
much needed visibility into streams topologies among other niceties. But at the
same time, I am concerned about a new external service dependency that users
need to take on. thoughts?
I think Schema
> Add mechanism to detect topology mismatch between streams instances
> -------------------------------------------------------------------
>
> Key: KAFKA-8810
> URL: https://issues.apache.org/jira/browse/KAFKA-8810
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Vinoth Chandar
> Priority: Major
>
> Noticed this while reading through the StreamsPartitionAssignor related code.
> If an user accidentally deploys a different topology on one of the instances,
> there is no mechanism to detect this and refuse assignment/take action. Given
> Kafka Streams is designed as an embeddable library, I feel this is rather an
> important scenario to handle. For e.g, kafka streams is embedded into a web
> front end tier and operators deploy a hot fix for a site issue to a few
> instances that are leaking memory and that accidentally also deploys some
> topology changes with it.
> Please feel free to close the issue, if its a duplicate. (Could not find a
> ticket for this)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
