[ 
https://issues.apache.org/jira/browse/FLINK-29199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17760361#comment-17760361
 ] 

Nicolas Fraison commented on FLINK-29199:
-----------------------------------------

This is indeed a concern we have as we rely on kafka data sources.

Currently we are thinking on relying on 2 different kafka consumer group (one 
blue and one green) for those 2 jobs. I need to validate that resuming the 
green deployment from blue checkpoint with a different consumer group can be 
done.

For the double data output we can tolerate some duplicate for those specific 
jobs

> Support blue-green deployment type
> ----------------------------------
>
>                 Key: FLINK-29199
>                 URL: https://issues.apache.org/jira/browse/FLINK-29199
>             Project: Flink
>          Issue Type: New Feature
>          Components: Kubernetes Operator
>         Environment: Kubernetes
>            Reporter: Oleg Vorobev
>            Priority: Minor
>
> Are there any plans to support blue-green deployment/rollout mode similar to 
> *BlueGreen* in the 
> [flinkk8soperator|https://github.com/lyft/flinkk8soperator] to avoid downtime 
> while updating?
> The idea is to run a new version in parallel with an old one and remove the 
> old one only after the stability condition of the new one is satisfied (like 
> in 
> [rollbacks|https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-release-1.1/docs/custom-resource/job-management/#application-upgrade-rollbacks-experimental]).
> For stateful apps with {*}upgradeMode: savepoint{*}, this means: not 
> cancelling an old job after creating a savepoint -> starting new job from 
> that savepoint -> waiting for it to become running/one successful 
> checkpoint/timeout or something else -> cancelling and removing old job.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to