[
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 10:57 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.
was (Author: JIRAUSER285640):
Is the idea of this issue to migrate the current custom `Status` objects to a
more uniform and standardized spec?
I think the Condition K8 spec could be a good migration - the caveat being that
it is more annoying to search through a list for something like
`.getStatus().getJobStatus().getState()` which is used throughout the operator.
That being said, I think duplication of the logic would lead to a weird
situation where there is a Condition with type:Ready and having `JobStatus` in
the `.status.jobStatus`?
I'm not an operator expert but is this common to duplicate? If yes, (y). If no,
any smart idea how to make it less annoying to consistently search through all
of the Conditions in the operator code?
Maybe it is easiest to start with something like `jobManagerDeploymentStatus`.
It seems pretty innocuous
Thoughts on starting with what currently exists in the
`jobManagerDeploymentStatus`. It might make more sense as a condition than a
separate status object. There might be other custom status objects that could
also be standardized eventually. The caveat being the
`jobManagerDeploymentStatus` is used
Potentially moving towards a spec for the 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)
