You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by David Radley <da...@uk.ibm.com> on 2025/11/10 11:22:42 UTC
Proposal to add a new
Hi,
We are opinionated about which Flink image we would like the Flink Kubernetes operator to use. So in the flink-kubenetes-operator the ReconciliationUtils prior to [1] we are patching in code to trigger the update of the FlinkDeployment resource if needed with a new Flink image from an environment variable.
We would like to avoid needing to patch the code, so are thinking that the way to do this would be to have a new discover pattern to bring in our code from the plugins folder in a similar way to ListenerUtils[2], that would allow us to force an update of the Flink Deployment with something like:
forceReconcilers= ReconciliationUtils.discoverForceReconcilers(configManager);
for ( ForceReconciler forceReconciler: forceReconcilers) {
If (forceReconciler.shouldForceUpdate(current)) {
updateControl = UpdateControl.updateResource(current);
}
}
Just before [1].
This would allow us to supply code as a plugin that would test our environment variable and see if we need to force an update of the deployment.
I am happy to code this ,
Kind regards, David.
[1] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/reconciler/ReconciliationUtils.java#L290
[2] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/listener/ListenerUtils.java#L69C53-L69C70
Kind regards, David.
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
RE: Proposal to add a new discovery plugin to the k8s operator
Posted by David Radley <da...@uk.ibm.com>.
Hi Gyula,
Thanks for your quick response. Triggered by your thought around environment variable-based reconciliation, we are now thinking that we could just have:
private static final String TRIGGER_FLINK_RESOURCE_RECONCILIATION = System.getenv("TRIGGER_FLINK_RESOURCE_RECONCILIATION");
And
if (TRIGGER_RESOURCE_RECONCILIATION != null && "true".equalsIgnoreCase(TRIGGER_FLINK_RESOURCE_RECONCILE)) {
LOG.info("Triggering resource reconciliation due to environment variable.");
updateControl = UpdateControl.updateResource(current);
}
And test.
WDYT? If you are ok with it - would you want a Flip or just a Jira? Happy for your input on the environment variable name.
Kind regards, David.
From: gyula.fora@gmail.com <gy...@gmail.com>
Date: Tuesday, 11 November 2025 at 04:59
To: dev@flink.apache.org <de...@flink.apache.org>
Cc: dev <de...@flink.apache.org>
Subject: [EXTERNAL] Re: Proposal to add a new discovery plugin to the k8s operator
Hey!
Thanks for the proposal.
In general I think it’s a good idea to expose a pluggable reconciler mechanism. Maybe ForceReconciler is not a good name (not sure what is forceful about it :) ) probably simply FlinkResourceReconciler would do .
The questions in this particular case for the env variable based reconciliation is whether this is something that we should support as a feature or not .
I think both of these would deserve their independent FLIP with the interfaces and 1-2 example implementations to put them into context .
Cheers
Gyula
Sent from my iPhone
> On 10 Nov 2025, at 13:39, David Radley <da...@uk.ibm.com> wrote:
>
> Hi,
> We are opinionated about which Flink image we would like the Flink Kubernetes operator to use. So in the flink-kubenetes-operator the ReconciliationUtils prior to [1] we are patching in code to trigger the update of the FlinkDeployment resource if needed with a new Flink image from an environment variable.
>
> We would like to avoid needing to patch the code, so are thinking that the way to do this would be to have a new discover pattern to bring in our code from the plugins folder in a similar way to ListenerUtils[2], that would allow us to force an update of the Flink Deployment with something like:
>
>
> forceReconcilers= ReconciliationUtils.discoverForceReconcilers(configManager);
>
>
> for ( ForceReconciler forceReconciler: forceReconcilers) {
>
> If (forceReconciler.shouldForceUpdate(current)) {
>
> updateControl = UpdateControl.updateResource(current);
>
> }
>
> }
>
>
> Just before [1].
>
> This would allow us to supply code as a plugin that would test our environment variable and see if we need to force an update of the deployment.
>
> I am happy to code this ,
> Kind regards, David.
>
> [1] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/reconciler/ReconciliationUtils.java#L290
> [2] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/listener/ListenerUtils.java#L69C53-L69C70
>
> Kind regards, David.
>
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
RE: Proposal to add a new discovery plugin to the k8s operator
Posted by David Radley <da...@uk.ibm.com>.
Hi again,
Fyi we need to rethink, as the method we want to call
UpdateControl.updateResource
Is no longer there at the later level of operator sdk that main is using.
Kind regards, David.
From: gyula.fora@gmail.com <gy...@gmail.com>
Date: Tuesday, 11 November 2025 at 04:59
To: dev@flink.apache.org <de...@flink.apache.org>
Cc: dev <de...@flink.apache.org>
Subject: [EXTERNAL] Re: Proposal to add a new discovery plugin to the k8s operator
Hey!
Thanks for the proposal.
In general I think it’s a good idea to expose a pluggable reconciler mechanism. Maybe ForceReconciler is not a good name (not sure what is forceful about it :) ) probably simply FlinkResourceReconciler would do .
The questions in this particular case for the env variable based reconciliation is whether this is something that we should support as a feature or not .
I think both of these would deserve their independent FLIP with the interfaces and 1-2 example implementations to put them into context .
Cheers
Gyula
Sent from my iPhone
> On 10 Nov 2025, at 13:39, David Radley <da...@uk.ibm.com> wrote:
>
> Hi,
> We are opinionated about which Flink image we would like the Flink Kubernetes operator to use. So in the flink-kubenetes-operator the ReconciliationUtils prior to [1] we are patching in code to trigger the update of the FlinkDeployment resource if needed with a new Flink image from an environment variable.
>
> We would like to avoid needing to patch the code, so are thinking that the way to do this would be to have a new discover pattern to bring in our code from the plugins folder in a similar way to ListenerUtils[2], that would allow us to force an update of the Flink Deployment with something like:
>
>
> forceReconcilers= ReconciliationUtils.discoverForceReconcilers(configManager);
>
>
> for ( ForceReconciler forceReconciler: forceReconcilers) {
>
> If (forceReconciler.shouldForceUpdate(current)) {
>
> updateControl = UpdateControl.updateResource(current);
>
> }
>
> }
>
>
> Just before [1].
>
> This would allow us to supply code as a plugin that would test our environment variable and see if we need to force an update of the deployment.
>
> I am happy to code this ,
> Kind regards, David.
>
> [1] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/reconciler/ReconciliationUtils.java#L290
> [2] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/listener/ListenerUtils.java#L69C53-L69C70
>
> Kind regards, David.
>
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
FW: RE: Proposal to add a new discovery plugin to the k8s operator
Posted by David Radley <da...@uk.ibm.com>.
Hi Gyora,
I wanted to explain our motivation around what we have done, to see if there might be a better approach to achieve what we want.
In our operator deployment there is a custom Flink image that we specify in the spec. The name of the image has our IBM prefix. When we upgrade via a helm apply, the new image location is put into an environment variable. We wrote a patch in the reconciler, if there is our environment variable , and the existing image has our prefix and the environment variable is different from what we already have in the spec.image then we drive an update. The update has a web hook mutator that will update the spec.image. The spec image update will then cause the reconciler to update the managed resources with it. In this way we pick up new versions of our custom image.
We did not know any other way of doing this and are open to suggestions if there is a slicker approach we could take.
This code change is currently in a patch, we would like to get rid of the patch. We could do this:
* Via a plugin, where we could use the same logic as is in the patch, updated to use the latest method name for the operator sdk.
* In some more generic way, if we think others might need this. This could be done having the operator code be aware of Environment variables pointing to custom image locations.
WDYT?
Kind regards, David.
From: David Radley <da...@uk.ibm.com>
Date: Wednesday, 12 November 2025 at 17:00
To: dev@flink.apache.org <de...@flink.apache.org>
Subject: [EXTERNAL] RE: Proposal to add a new discovery plugin to the k8s operator
Hi Gyula,
We realise that the latest operator sdk does not have the UpdateControl.updateResource method. We need to upgrade our use of the operator and do more investigation into the approach we want to take before proposing something in open source. I will continue this thread when we have more clarity,
Many thanks , David.
From: David Radley <da...@uk.ibm.com>
Date: Wednesday, 12 November 2025 at 16:16
To: dev@flink.apache.org <de...@flink.apache.org>
Subject: [EXTERNAL] RE: Proposal to add a new discovery plugin to the k8s operator
Hi Gyula,
Thanks for your quick response. Based on your thought about env variable based reconciliation, it would be sufficient for us to have a change like :
private static final String TRIGGER_RESOURCE_RECONCILIATION = System.getenv("TRIGGER_RESOURCE_RECONCILIATION");
if (TRIGGER_RESOURCE_RECONCILIATION != null && "true".equalsIgnoreCase(TRIGGER_RESOURCE_RECONCILIATION)) {
LOG.info("Triggering resource reconciliation due to environment variable.");
updateControl = UpdateControl.updateResource(current);
}
WDYT? Happy to change the name of the environment variable. If this works for you, would you like a Flip for this or just a Jira?
Kind regards, David.
From: gyula.fora@gmail.com <gy...@gmail.com>
Date: Tuesday, 11 November 2025 at 04:59
To: dev@flink.apache.org <de...@flink.apache.org>
Cc: dev <de...@flink.apache.org>
Subject: [EXTERNAL] Re: Proposal to add a new discovery plugin to the k8s operator
Hey!
Thanks for the proposal.
In general I think it’s a good idea to expose a pluggable reconciler mechanism. Maybe ForceReconciler is not a good name (not sure what is forceful about it :) ) probably simply FlinkResourceReconciler would do .
The questions in this particular case for the env variable based reconciliation is whether this is something that we should support as a feature or not .
I think both of these would deserve their independent FLIP with the interfaces and 1-2 example implementations to put them into context .
Cheers
Gyula
Sent from my iPhone
> On 10 Nov 2025, at 13:39, David Radley <da...@uk.ibm.com> wrote:
>
> Hi,
> We are opinionated about which Flink image we would like the Flink Kubernetes operator to use. So in the flink-kubenetes-operator the ReconciliationUtils prior to [1] we are patching in code to trigger the update of the FlinkDeployment resource if needed with a new Flink image from an environment variable.
>
> We would like to avoid needing to patch the code, so are thinking that the way to do this would be to have a new discover pattern to bring in our code from the plugins folder in a similar way to ListenerUtils[2], that would allow us to force an update of the Flink Deployment with something like:
>
>
> forceReconcilers= ReconciliationUtils.discoverForceReconcilers(configManager);
>
>
> for ( ForceReconciler forceReconciler: forceReconcilers) {
>
> If (forceReconciler.shouldForceUpdate(current)) {
>
> updateControl = UpdateControl.updateResource(current);
>
> }
>
> }
>
>
> Just before [1].
>
> This would allow us to supply code as a plugin that would test our environment variable and see if we need to force an update of the deployment.
>
> I am happy to code this ,
> Kind regards, David.
>
> [1] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/reconciler/ReconciliationUtils.java#L290
> [2] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/listener/ListenerUtils.java#L69C53-L69C70
>
> Kind regards, David.
>
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
RE: Proposal to add a new discovery plugin to the k8s operator
Posted by David Radley <da...@uk.ibm.com>.
Hi Gyula,
We realise that the latest operator sdk does not have the UpdateControl.updateResource method. We need to upgrade our use of the operator and do more investigation into the approach we want to take before proposing something in open source. I will continue this thread when we have more clarity,
Many thanks , David.
From: David Radley <da...@uk.ibm.com>
Date: Wednesday, 12 November 2025 at 16:16
To: dev@flink.apache.org <de...@flink.apache.org>
Subject: [EXTERNAL] RE: Proposal to add a new discovery plugin to the k8s operator
Hi Gyula,
Thanks for your quick response. Based on your thought about env variable based reconciliation, it would be sufficient for us to have a change like :
private static final String TRIGGER_RESOURCE_RECONCILIATION = System.getenv("TRIGGER_RESOURCE_RECONCILIATION");
if (TRIGGER_RESOURCE_RECONCILIATION != null && "true".equalsIgnoreCase(TRIGGER_RESOURCE_RECONCILIATION)) {
LOG.info("Triggering resource reconciliation due to environment variable.");
updateControl = UpdateControl.updateResource(current);
}
WDYT? Happy to change the name of the environment variable. If this works for you, would you like a Flip for this or just a Jira?
Kind regards, David.
From: gyula.fora@gmail.com <gy...@gmail.com>
Date: Tuesday, 11 November 2025 at 04:59
To: dev@flink.apache.org <de...@flink.apache.org>
Cc: dev <de...@flink.apache.org>
Subject: [EXTERNAL] Re: Proposal to add a new discovery plugin to the k8s operator
Hey!
Thanks for the proposal.
In general I think it’s a good idea to expose a pluggable reconciler mechanism. Maybe ForceReconciler is not a good name (not sure what is forceful about it :) ) probably simply FlinkResourceReconciler would do .
The questions in this particular case for the env variable based reconciliation is whether this is something that we should support as a feature or not .
I think both of these would deserve their independent FLIP with the interfaces and 1-2 example implementations to put them into context .
Cheers
Gyula
Sent from my iPhone
> On 10 Nov 2025, at 13:39, David Radley <da...@uk.ibm.com> wrote:
>
> Hi,
> We are opinionated about which Flink image we would like the Flink Kubernetes operator to use. So in the flink-kubenetes-operator the ReconciliationUtils prior to [1] we are patching in code to trigger the update of the FlinkDeployment resource if needed with a new Flink image from an environment variable.
>
> We would like to avoid needing to patch the code, so are thinking that the way to do this would be to have a new discover pattern to bring in our code from the plugins folder in a similar way to ListenerUtils[2], that would allow us to force an update of the Flink Deployment with something like:
>
>
> forceReconcilers= ReconciliationUtils.discoverForceReconcilers(configManager);
>
>
> for ( ForceReconciler forceReconciler: forceReconcilers) {
>
> If (forceReconciler.shouldForceUpdate(current)) {
>
> updateControl = UpdateControl.updateResource(current);
>
> }
>
> }
>
>
> Just before [1].
>
> This would allow us to supply code as a plugin that would test our environment variable and see if we need to force an update of the deployment.
>
> I am happy to code this ,
> Kind regards, David.
>
> [1] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/reconciler/ReconciliationUtils.java#L290
> [2] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/listener/ListenerUtils.java#L69C53-L69C70
>
> Kind regards, David.
>
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
RE: Proposal to add a new discovery plugin to the k8s operator
Posted by David Radley <da...@uk.ibm.com>.
Hi Gyula,
Thanks for your quick response. Based on your thought about env variable based reconciliation, it would be sufficient for us to have a change like :
private static final String TRIGGER_RESOURCE_RECONCILIATION = System.getenv("TRIGGER_RESOURCE_RECONCILIATION");
if (TRIGGER_RESOURCE_RECONCILIATION != null && "true".equalsIgnoreCase(TRIGGER_RESOURCE_RECONCILIATION)) {
LOG.info("Triggering resource reconciliation due to environment variable.");
updateControl = UpdateControl.updateResource(current);
}
WDYT? Happy to change the name of the environment variable. If this works for you, would you like a Flip for this or just a Jira?
Kind regards, David.
From: gyula.fora@gmail.com <gy...@gmail.com>
Date: Tuesday, 11 November 2025 at 04:59
To: dev@flink.apache.org <de...@flink.apache.org>
Cc: dev <de...@flink.apache.org>
Subject: [EXTERNAL] Re: Proposal to add a new discovery plugin to the k8s operator
Hey!
Thanks for the proposal.
In general I think it’s a good idea to expose a pluggable reconciler mechanism. Maybe ForceReconciler is not a good name (not sure what is forceful about it :) ) probably simply FlinkResourceReconciler would do .
The questions in this particular case for the env variable based reconciliation is whether this is something that we should support as a feature or not .
I think both of these would deserve their independent FLIP with the interfaces and 1-2 example implementations to put them into context .
Cheers
Gyula
Sent from my iPhone
> On 10 Nov 2025, at 13:39, David Radley <da...@uk.ibm.com> wrote:
>
> Hi,
> We are opinionated about which Flink image we would like the Flink Kubernetes operator to use. So in the flink-kubenetes-operator the ReconciliationUtils prior to [1] we are patching in code to trigger the update of the FlinkDeployment resource if needed with a new Flink image from an environment variable.
>
> We would like to avoid needing to patch the code, so are thinking that the way to do this would be to have a new discover pattern to bring in our code from the plugins folder in a similar way to ListenerUtils[2], that would allow us to force an update of the Flink Deployment with something like:
>
>
> forceReconcilers= ReconciliationUtils.discoverForceReconcilers(configManager);
>
>
> for ( ForceReconciler forceReconciler: forceReconcilers) {
>
> If (forceReconciler.shouldForceUpdate(current)) {
>
> updateControl = UpdateControl.updateResource(current);
>
> }
>
> }
>
>
> Just before [1].
>
> This would allow us to supply code as a plugin that would test our environment variable and see if we need to force an update of the deployment.
>
> I am happy to code this ,
> Kind regards, David.
>
> [1] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/reconciler/ReconciliationUtils.java#L290
> [2] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/listener/ListenerUtils.java#L69C53-L69C70
>
> Kind regards, David.
>
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
Re: Proposal to add a new discovery plugin to the k8s operator
Posted by gy...@gmail.com.
Hey!
Thanks for the proposal.
In general I think it’s a good idea to expose a pluggable reconciler mechanism. Maybe ForceReconciler is not a good name (not sure what is forceful about it :) ) probably simply FlinkResourceReconciler would do .
The questions in this particular case for the env variable based reconciliation is whether this is something that we should support as a feature or not .
I think both of these would deserve their independent FLIP with the interfaces and 1-2 example implementations to put them into context .
Cheers
Gyula
Sent from my iPhone
> On 10 Nov 2025, at 13:39, David Radley <da...@uk.ibm.com> wrote:
>
> Hi,
> We are opinionated about which Flink image we would like the Flink Kubernetes operator to use. So in the flink-kubenetes-operator the ReconciliationUtils prior to [1] we are patching in code to trigger the update of the FlinkDeployment resource if needed with a new Flink image from an environment variable.
>
> We would like to avoid needing to patch the code, so are thinking that the way to do this would be to have a new discover pattern to bring in our code from the plugins folder in a similar way to ListenerUtils[2], that would allow us to force an update of the Flink Deployment with something like:
>
>
> forceReconcilers= ReconciliationUtils.discoverForceReconcilers(configManager);
>
>
> for ( ForceReconciler forceReconciler: forceReconcilers) {
>
> If (forceReconciler.shouldForceUpdate(current)) {
>
> updateControl = UpdateControl.updateResource(current);
>
> }
>
> }
>
>
> Just before [1].
>
> This would allow us to supply code as a plugin that would test our environment variable and see if we need to force an update of the deployment.
>
> I am happy to code this ,
> Kind regards, David.
>
> [1] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/reconciler/ReconciliationUtils.java#L290
> [2] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/listener/ListenerUtils.java#L69C53-L69C70
>
> Kind regards, David.
>
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
Proposal to add a new discovery plugin to the k8s operator
Posted by David Radley <da...@uk.ibm.com>.
Hi,
We are opinionated about which Flink image we would like the Flink Kubernetes operator to use. So in the flink-kubenetes-operator the ReconciliationUtils prior to [1] we are patching in code to trigger the update of the FlinkDeployment resource if needed with a new Flink image from an environment variable.
We would like to avoid needing to patch the code, so are thinking that the way to do this would be to have a new discover pattern to bring in our code from the plugins folder in a similar way to ListenerUtils[2], that would allow us to force an update of the Flink Deployment with something like:
forceReconcilers= ReconciliationUtils.discoverForceReconcilers(configManager);
for ( ForceReconciler forceReconciler: forceReconcilers) {
If (forceReconciler.shouldForceUpdate(current)) {
updateControl = UpdateControl.updateResource(current);
}
}
Just before [1].
This would allow us to supply code as a plugin that would test our environment variable and see if we need to force an update of the deployment.
I am happy to code this ,
Kind regards, David.
[1] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/reconciler/ReconciliationUtils.java#L290
[2] https://github.com/apache/flink-kubernetes-operator/blob/eb99c5a12c6d93b9f303d8ac8d028ab28bb13689/flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/listener/ListenerUtils.java#L69C53-L69C70
Kind regards, David.
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
Unless otherwise stated above:
IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN