Hi Matyas, Thanks for the feedback, and yes I agree. An alternative approach would instead be:
- 2 API calls only when jobID is not available (i.e when submitting a new application cluster, which is a one-off event). - 1 API call when jobID is already available by directly calling "/jobs/:jobid". With this approach, we can keep the API call to 1 in most cases. Regards, Daren On 11/07/2022, 14:44, "Őrhidi Mátyás" <matyas.orh...@gmail.com> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Daren, At the moment the Operator fetches the job state via https://nightlies.apache.org/flink/flink-docs-master/docs/ops/rest_api/#jobs-overview which contains the 'end-time' and 'duration' fields already. I feel calling the https://nightlies.apache.org/flink/flink-docs-master/docs/ops/rest_api/#jobs-jobid after the previous call for every job in every reconcile loop would be too expensive. Best, Matyas On Mon, Jul 11, 2022 at 3:17 PM WONG, DAREN <daren...@amazon.co.uk.invalid> wrote: > Hi everyone, I am Daren from AWS Kinesis Data Analytics (KDA) team. I had > a quick chat with Gyula as I propose to include a few additional fields in > the jobStatus CRD for Flink Kubernetes Operator such as: > > - endTime > - duration > - jobPlan > > Further details of each states can be found here< > https://github.com/darenwkt/flink/blob/release-1.15.0/flink-runtime/src/main/java/org/apache/flink/runtime/rest/messages/job/JobDetailsInfo.java>. > Although addition of these 3 states stem from an internal requirement, I > think they would be beneficial to others who uses these states in their > application as well. The list of states above are not exhaustive, so do let > me know if there are other states that you would like to include together > in this iteration cycle. > > JIRA: https://issues.apache.org/jira/browse/FLINK-28494 >