Thanks for the proposal. These changes will make it significantly easier to programmatically use Flink in downstream frameworks.
Should the new Executor execute method be defined as asynchronous? It could return a job handle to interact with the job and the legacy environments can still block to retain their semantics. (The blocking execution has also made things more difficult in Beam, we could simply switch to use Executor directly.) Thomas On Tue, Sep 24, 2019 at 6:48 AM Kostas Kloudas <kklou...@apache.org> wrote: > Hi all, > > In the context of the discussion about introducing the Job Client API [1], > there was a side-discussion about refactoring the way users submit jobs in > Flink. There were many different interesting ideas on the topic and 3 > design documents that were trying to tackle both the issue about code > submission and the Job Client API. > > This discussion thread aims at the job submission part and proposes the > approach of introducing the Executor abstraction which will abstract the > job submission logic from the Environments and will make it API agnostic. > > The FLIP can be found at [2]. > > Please keep the discussion here, in the mailing list. > > Looking forward to your opinions, > Kostas > > [1] > > https://lists.apache.org/thread.html/ce99cba4a10b9dc40eb729d39910f315ae41d80ec74f09a356c73938@%3Cdev.flink.apache.org%3E > [2] > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-73%3A+Introducing+Executors+for+job+submission >
