I share mytyas's concern if we list the jobs first and then followed by some get-job-detail requests. It is a bit expensive and I do not see the benefit to store jobPlan in the CR status.
Best, Yang Őrhidi Mátyás <matyas.orh...@gmail.com> 于2022年7月11日周一 21:43写道： > 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 > > >
