TisonKun commented on issue #10311: [FLINK-14762][client] Enrich JobClient API URL: https://github.com/apache/flink/pull/10311#issuecomment-559635706 cherry-pick from slack channel. feel free to react wherever you like. >Sorry but when rebasing I cannot convince myself about why we introduce a flink-core variant of `JobStatus`? `ClusterClient` will return runtime `JobStatus` while `JobClient` returns `JobStatus`. It doesn’t make sense to me for introducing such different. >Runtime version `JobStatus` doesn’t depend on anything inside runtime but a self-contained enum. Shall we add it into `o.a.f.api.common`? Different from ClosureCleaner which could be used by connectors I think `JobStatus` is previously totally internal concept that should not breaks user setups and dependencies if we move it. >I’ve pushed a set of commits that we all agree on. The remain problem is about `getJobStatus` and `getAccumulator` > >for `getJobStatus` the main concern is about where `JobStatus` stays and whether we introduce a variant of `JobStatus`. My opinion is above. for `getAccumulator` the main concern is about whether Flink does unpack job for the user. I think we can do so, but maybe in another pass of pull request so that we firstly move forward this set under consensus. So my idea is that we commit this set of commit as part 1 of FLINK-14762 and I start a new pull request refactor `getAccumulator` and then implement its `JobClient` interface. While let’s align about `JobStatus` . Another coin about `JobStatus` is that we already display this sort of status on WebUI so it is reasonable to be core/common api(at least it is effectively user-facing).
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
