[
https://issues.apache.org/jira/browse/KAFKA-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824716#comment-16824716
]
Guozhang Wang commented on KAFKA-8236:
--------------------------------------
In order to understand the scope of this proposed versioning, we should
consider firstly what the versioning would be used. A couple of questions in my
mind:
1) Consider an app upgraded from version A to version B while there are still
some un-consumed data in the intermediate topics, how should the application
handle it? Or in other words, should we consider to shut down an app at a
consistent snapshot with no un-consumed intermediate data first of all?
2) If an app's version A and version B has different repartition topics or
state stores, how should the application handle it? Or in other words, how
should we determine if new versions are compatible with old versions and hence
can be restarted smoothly?
3) If an app's version does not change, but the scalability unit changes? For
example, input topic num.partitions changes.
> Incorporate version control for Kafka Streams Application Reset
> ---------------------------------------------------------------
>
> Key: KAFKA-8236
> URL: https://issues.apache.org/jira/browse/KAFKA-8236
> Project: Kafka
> Issue Type: Improvement
> Components: streams, tools
> Reporter: Boyang Chen
> Priority: Minor
> Labels: needs-kip
>
> Inspired by Spark mlflow which supports versioning log, we should be
> considering expose a special versioning tag for KStream applications to easy
> rollback bad code deploy. The naive approach is to store the versioning info
> in consumer offset topic so that when we perform rollback, we know where to
> read from the input, and where to cleanup the changelog topic. Essentially,
> this is an extension to our current application reset tool.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
