[
https://issues.apache.org/jira/browse/FLINK-33634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795126#comment-17795126
]
Ryan van Huuksloot edited comment on FLINK-33634 at 12/10/23 11:00 PM:
-----------------------------------------------------------------------
Is the idea of this issue to migrate the current custom `Status` objects to a
more uniform and standardized spec? It would lead to a duplication of logic
where there is a Condition with `type:Ready` and having `JobStatus` in the
`.status.jobStatus`.
*Note: I think `type: Ready` is too vague for Flink.*
I'm not an operator expert but is it common to duplicate with objects and
Conditions in status?
If yes, (y) you can ignore the rest of the post.
If no, any smart idea how to make it less annoying to consistently search
through all of the Conditions in the operator code? (There is a lot of usages
in the operator of `.getStatus().getJobStatus().getState()`)
Maybe it is easiest to start with something like `jobManagerDeploymentStatus`.
It seems pretty innocuous and we could duplicate the implementation in the
short term.
Potentially moving towards a spec for FlinkDeployment like:
```
status:
conditions:
- type: JobManagerReady
status: "True"
lastTransitionTime: '2023-11-23T12:38:51Z'
lastHeartbeatTime: '2023-11-23T12:39:51Z'
observedGeneration: 1
reason: Ready
message: "JobManager is running and ready to receive REST API calls."
- type: ReconciliationSucceeded
status: "True"
lastTransitionTime: '2023-11-23T12:38:51Z'
reason: ReconciliationSucceeded
message: "Reconciliation succeeded."
- type: JobRunning
status: "True"
lastTransitionTime: '2023-11-23T12:38:51Z'
lastHeartbeatTime: '2023-11-23T12:40:51Z'
observedGeneration: 12
reason: Running
message: "Job is running."
jobId: 0b0f0c0a-0b0f-0c0a-0b0f-0c0a0b0f0c0a
jobName: flink-kubernetes-operator-test
```
Could add information about the Savepoint/Checkpoint as well.
Apologies if you got spam emailed. It kept submitting when trying to do same
paragraph new lines.
was (Author: JIRAUSER285640):
Is the idea of this issue to migrate the current custom `Status` objects to a
more uniform and standardized spec? It would lead to a duplication of logic
where there is a Condition with `type:Ready` and having `JobStatus` in the
`.status.jobStatus`.
*Note: I think `type: Ready` is too vague for Flink.*
I'm not an operator expert but is it common to duplicate with objects and
Conditions in status?
If yes, (y) you can ignore the rest of the post.
If no, any smart idea how to make it less annoying to consistently search
through all of the Conditions in the operator code? (There is a lot of usages
in the operator of `.getStatus().getJobStatus().getState()`)
Maybe it is easiest to start with something like `jobManagerDeploymentStatus`.
It seems pretty innocuous and we could duplicate the implementation in the
short term.
Potentially moving towards a spec for FlinkDeployment like:
```
status:
conditions:
- type: JobManagerReady
status: "True"
lastTransitionTime: '2023-11-23T12:38:51Z'
lastHeartbeatTime: '2023-11-23T12:39:51Z'
observedGeneration: 1
reason: Ready
message: "JobManager is running and ready to receive REST API calls."
- type: ReconciliationSucceeded
status: "True"
lastTransitionTime: '2023-11-23T12:38:51Z'
reason: ReconciliationSucceeded
message: "Reconciliation succeeded."
- type: JobRunning
status: "True"
lastTransitionTime: '2023-11-23T12:38:51Z'
lastHeartbeatTime: '2023-11-23T12:40:51Z'
observedGeneration: 12
reason: Running
message: "Job is running."
jobId: 0b0f0c0a-0b0f-0c0a-0b0f-0c0a0b0f0c0a
jobName: flink-kubernetes-operator-test
```
Could add information about the Savepoint/Checkpoint as well.
> Add Conditions to Flink CRD's Status field
> ------------------------------------------
>
> Key: FLINK-33634
> URL: https://issues.apache.org/jira/browse/FLINK-33634
> Project: Flink
> Issue Type: Improvement
> Components: Kubernetes Operator
> Affects Versions: kubernetes-operator-1.7.0
> Reporter: Tony Garrard
> Priority: Major
>
> From
> [https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties]
> it is considered best practice to provide Conditions in the Status of CRD's.
> Some tooling even expects there to be a Conditions field in the status of a
> CR. This issue to to propose adding a Conditions field to the CR status
> e.g.
> status:
> conditions:
> - lastTransitionTime: '2023-11-23T12:38:51Z'
> status: 'True'
> type: Ready
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
