[
https://issues.apache.org/jira/browse/FLINK-29199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17609438#comment-17609438
]
Oleg Vorobev commented on FLINK-29199:
--------------------------------------
[~gyfora], thanks for your suggestion about custom implementation, not sure if
I understand the problem with *cluster-id* that you described (I haven't tried
this operator yet).
Are you saying that currently *cluster-id* is picked from the configuration and
used as is without, for example, adding a hash of meaningful fields from CR or
something like that?
Does it mean that creating 2 similar *FlinkDeployment* objects in the same
namespace with different object names and *image* fields, configured to use
Kubernetes HA will not work properly and will interfere with each other (will
use the same configmaps?).
> 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)
