[
https://issues.apache.org/jira/browse/FLINK-33634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795126#comment-17795126
]
Ryan van Huuksloot commented on FLINK-33634:
--------------------------------------------
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)