[
https://issues.apache.org/jira/browse/FLINK-29199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17609442#comment-17609442
]
Gyula Fora commented on FLINK-29199:
------------------------------------
What I was saying is that cluster-id which must be unique within a namespace is
currently tied to the name of the FlinkDeployment.
If you create 2 flinkdeployments, they will have different names so different
cluster-ids. But since we cannot deploy 2 jobs using the same cluster-id for a
single FlinkDeployment we would have to completely rework this logic whihc
would have many implications to last-state recovery , HA etc.
> 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)
