Skip to content

[FLINK-33634] Add Conditions to Flink CRD's Status field #957

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Original file line number Diff line number Diff line change
Expand Up @@ -18,17 +18,22 @@
package org.apache.flink.kubernetes.operator.api.status;

import org.apache.flink.annotation.Experimental;
import org.apache.flink.api.common.JobStatus;
import org.apache.flink.kubernetes.operator.api.spec.FlinkDeploymentSpec;
import org.apache.flink.kubernetes.operator.api.utils.ConditionUtils;

import com.fasterxml.jackson.annotation.JsonIgnoreProperties;
import io.fabric8.kubernetes.api.model.Condition;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.EqualsAndHashCode;
import lombok.NoArgsConstructor;
import lombok.ToString;
import lombok.experimental.SuperBuilder;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

/** Last observed status of the Flink deployment. */
Expand All @@ -55,4 +60,175 @@ public class FlinkDeploymentStatus extends CommonStatus<FlinkDeploymentSpec> {

/** Information about the TaskManagers for the scale subresource. */
private TaskManagerInfo taskManager;

/** Condition of the CR . */
private List<Condition> conditions = new ArrayList<>();

private String phase;

public List<Condition> getConditions() {
if (reconciliationStatus != null

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am curious which parts of the code refer to application mode and which are session cluster. It would be good to have some comments to detail this and maybe use the mode name in method name or variable names to make this more intuitive to read.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will add comments in the respective code.

&& reconciliationStatus.deserializeLastReconciledSpec() != null
&& reconciliationStatus.deserializeLastReconciledSpec().getJob() == null) {
switch (jobManagerDeploymentStatus) {
Copy link

@davidradl davidradl Mar 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we have a datastructure, keyed off the jobManagerDeploymentStatus, that we interrogate to get the inserts for the updateConditions. Maybe a map with the key of the status and the value of an object RunningCondition, that has 2 fields the boolean and the description. Something like :


Map<JobManagerDeploymentStatus,String> jobmanagerDeploymentStatusMap = new HashMap<String,String>() {{
    put(READY, new RunningCondition(true, "JobManager is running and ready to receive REST API calls")),
    ....
}}; 

then the code just loops through the map updating conditions using the map values. Similar for jobstatus

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering will that add any value?. Any way to build the Map , we have to call ConditionUtils to build the Condition, so rather than have a Prebuild Map , we can directly call ConditionUtils to build them right. Your thoughts?.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you have pre built the map now - with map.of - looks good - thanks.

case READY:
Copy link

@davidradl davidradl Apr 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of this switch can we just issue

updateCondition(
                           conditions,
                           ConditionUtils.crCondition(
                                   ConditionUtils.SESSION_MODE_CONDITION.get(
                                           jobManagerDeploymentStatus.name())));

updateCondition(
conditions,
ConditionUtils.runningTrue(
"JobManager is running and ready to receive REST API call",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: call -> calls

"JobManager is running and ready to receive REST API call"));
break;
case MISSING:
updateCondition(
conditions,
ConditionUtils.runningFalse(
"JobManager deployment not found",
"JobManager deployment not found"));
break;
case DEPLOYING:
updateCondition(
conditions,
ConditionUtils.runningFalse(
"JobManager process is starting up",
"JobManager process is starting up"));

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am curious why the message and reaon is the same . I would expect them to be different. In this case I would expect the reason to be "A New JVM deployment exists and is being created" - i.e. the word on the arrow in the UML.

Copy link
Author

@lajith2006 lajith2006 Mar 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per description here which says Reason is intended to be a one-word, CamelCase representation of the category of cause of the current status, and Message is intended to be a human-readable phrase or sentence, I would use the existing enum https://github.com/apache/flink-kubernetes-operator/blob/main/flink-kubernetes-operator-api/src/main/java/org/apache/flink/kubernetes/operator/api/status/JobManagerDeploymentStatus.java, to use as reason and respective explanation as message

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see https://github.com/apache/flink-kubernetes-operator/pull/961/files, gives examples of camelcase single words reasons. We should follow that style for the cases that PR does not cover.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done a refactoring for the conditions.

break;
case DEPLOYED_NOT_READY:
updateCondition(
conditions,
ConditionUtils.runningFalse(
"JobManager is running but not ready yet to receive REST API calls",
"JobManager is running but not ready yet to receive REST API calls"));
break;
case ERROR:
updateCondition(
conditions,
ConditionUtils.runningFalse(
"Deployment in terminal error, requires spec change for reconciliation to continue",
"JobManager deployment failed"));
}
} else if (getJobStatus() != null && getJobStatus().getState() != null) {
switch (getJobStatus().getState()) {
Copy link

@davidradl davidradl Apr 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this switch as-is be replaced with

 updateCondition(
                            conditions,
                            ConditionUtils.crCondition(
                                    ConditionUtils.APPLICATION_MODE_CONDITION.get(
                                            getJobStatus().getState().name())));
 

case RECONCILING:
updateCondition(
conditions,
ConditionUtils.runningFalse(
JobStatus.RECONCILING.name(), "Job is currently reconciling"));
break;
case CREATED:
updateCondition(
conditions,
ConditionUtils.runningFalse(
JobStatus.CREATED.name(), "Job is created"));
break;
case RUNNING:
updateCondition(
conditions,
ConditionUtils.runningTrue(JobStatus.RUNNING.name(), "Job is running"));
break;
case FAILING:
updateCondition(
conditions,
ConditionUtils.runningFalse(
JobStatus.FAILING.name(), "Job has failed"));
break;
case RESTARTING:
updateCondition(
conditions,
ConditionUtils.runningFalse(
JobStatus.RESTARTING.name(),
"The job is currently undergoing a restarting"));

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "The job is currently undergoing a restarting" -> "The job is currently restarting"

break;
case FAILED:
updateCondition(
conditions,
ConditionUtils.runningFalse(
JobStatus.FAILED.name(),
"The job has failed with a non-recoverable task failure"));
break;
case FINISHED:
updateCondition(
conditions,
ConditionUtils.runningFalse(
JobStatus.FINISHED.name(),
"Job's tasks have successfully finished"));
break;

case CANCELED:
updateCondition(
conditions,
ConditionUtils.runningFalse(
JobStatus.CANCELED.name(), "Job has been cancelled"));
break;
case SUSPENDED:
updateCondition(
conditions,
ConditionUtils.runningFalse(
JobStatus.SUSPENDED.name(), "The job has been suspended"));
break;
}
}
return conditions;
}

public String getPhase() {
if (reconciliationStatus != null
&& reconciliationStatus.deserializeLastReconciledSpec() != null
&& reconciliationStatus.deserializeLastReconciledSpec().getJob() == null) {
switch (jobManagerDeploymentStatus) {
case READY:
phase = "Running";
break;
case MISSING:
case ERROR:
case DEPLOYING:
phase = "Pending";
break;
}
} else if (getJobStatus() != null && getJobStatus().getState() != null) {
switch (getJobStatus().getState()) {
case RECONCILING:
phase = "Pending";

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this one not RECONCILING like the pattern the others follow others? I suggest a comment, also a constant is better then a an inline literal.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, as mentioned here , phase which is intended to keep the current status of FlinkDeployment especially useful in Openshift environment, as Openshift UI can render the value from status.phase and populate the current status of deployment.

As when FlinkDeployment applied in Application Mode, in the initial phase, as the JM brining up , job state would be in RECONCILING state, so status.phase is kept as "Pending".

break;
case CREATED:
phase = JobStatus.CREATED.name();
break;
case RUNNING:
phase = JobStatus.RUNNING.name();
break;
case FAILING:
phase = JobStatus.FAILING.name();
break;
case RESTARTING:
phase = JobStatus.RESTARTING.name();
break;
case FAILED:
phase = JobStatus.FAILED.name();
break;
case FINISHED:
phase = JobStatus.FINISHED.name();
break;
case CANCELED:
phase = JobStatus.CANCELED.name();
break;
case SUSPENDED:
phase = JobStatus.SUSPENDED.name();
break;
}
}
return phase;
}

private static void updateCondition(List<Condition> conditions, Condition condition) {
if (conditions.isEmpty()) {
conditions.add(condition);
return;
}
// If new condition is same as last condition, ignore
Condition existingCondition = conditions.get(conditions.size() - 1);
if (existingCondition.getType().equals(condition.getType())
&& existingCondition.getMessage().equals(condition.getMessage())) {
return;
}
conditions.add(condition);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's maybe just me, just don't get how this list is truncated eventually, in other words, how is it prevented from growing indefinitely?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for review @csviri . Right now it's not preventing from growing indefinitely. As conditions reflects the different transitions state of Job/Deployment , thinking what could be the use case where can grow indefinitely?.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there should only ever be a single condition of type Running in the list that we return. Since we only have a single condition type right now, then the list should only have a single element. The latestTransition timestamp needs to represent when running changed from true->false or false->true. We can however keep updating the message if we want.

Copy link
Author

@lajith2006 lajith2006 Apr 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @gyfora for review , If I read correctly , you meant that we need to have only condition in the list at right now as we have only one type Running instead of multiple conditions of same type Running in the list as currently this PR having. And the lastTransitionTime in the condition must represent when the Running type changed its status from true>false or false > true. Is that correct?.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lajith2006 you say the lastTransitionTime in the condition must represent when the Running type changed its status from true>false or false > true. Is that correct?. So I am curious what happens in the history if we change the reason Text? Can you check that if we change the reason text and not the running flag, we see all of the entries in the history if all the historical conditions have the same lastTransitionTime with changing reasons.

}
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

package org.apache.flink.kubernetes.operator.api.utils;

import io.fabric8.kubernetes.api.model.Condition;
import io.fabric8.kubernetes.api.model.ConditionBuilder;

import java.text.SimpleDateFormat;
import java.util.Date;

/**
* Creates a condition object with the specified parameters.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: with the specified parameters -> whether this is running , the message and the reason.
then for return just say @return A condition

*
* @return A condition object with the type, message, status, reason and timestamp.
*/
public class ConditionUtils {
public static Condition runningTrue(final String message, final String reason) {
return crCondition("Running", "True", message, reason);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no need to pass "Running" as a parameter, we can hard code that in the method,

nit: rename crCondition -> crRunningCondition

Copy link
Author

@lajith2006 lajith2006 Mar 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to keep method name as crCondition rather crRunningCondition , just because , crCondition will keep it as more generic , so that if in case, if we need to address any other condition with type other than Running , we just need to pass parameter to build respective condition.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest doing that refactor when we need to, in the spirit of keeping the code lean.

}

public static Condition runningFalse(final String message, final String reason) {
return crCondition("Running", "False", message, reason);
Copy link

@davidradl davidradl Mar 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are there constants / enums for "False" and "True" we can use?
Os there an existing constant for "Running" we can use from OCP or the like. If not we should define this as a constant. We use this literal a few times in this change.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't see any existing enum/constants for "False" / "True , instead looks like used as string itself in wherever required in existing code.

}

private static Condition crCondition(
final String type, final String status, final String message, final String reason) {
return new ConditionBuilder()
.withType(type)
.withStatus(status)
.withMessage(message)
.withReason(reason)
.withLastTransitionTime(
new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss'Z'").format(new Date()))
.build();
}
}
Loading