Thanks for your replies.
Since no objection to Konstantin's proposal so far, I'd like to update
the FLIP correspondingly. They are naming issue and exclusion of
deprecated functionality.
I'm hereby infer that our community generally agree on the introduction
of the JobClient and its interfaces
I also agree @Zili Chen !
On Fri, Oct 4, 2019 at 10:17 AM Aljoscha Krettek wrote:
>
> This makes sense to me, yes!
>
> > On 2. Oct 2019, at 20:35, Zili Chen wrote:
> >
> > Hi all,
> >
> > Narrow the scope to FLIP-74 we aimed at introduce a useful and extensible
> > user-facing public interface
This makes sense to me, yes!
> On 2. Oct 2019, at 20:35, Zili Chen wrote:
>
> Hi all,
>
> Narrow the scope to FLIP-74 we aimed at introduce a useful and extensible
> user-facing public interface JobClient. Let me reemphasize two major works
> under this thread.
>
> 1. standard interface
>
>
Hi Kostas,
That is exactly how things go on in my mind and the reason I
say "integration to be a follow up discussion" :-)
Best,
tison.
Kostas Kloudas 于2019年10月3日周四 下午6:23写道：
> Hi Tison,
>
> I see. Then I would say that as a first step, and to see if people are
> happy with the result,
>
Hi Tison,
I see. Then I would say that as a first step, and to see if people are
happy with the result,
integration with the production code can be through a new method
executeAsync() in the Executor
that we discussed earlier.
This method could potentially be exposed to ExecutionEnvironment as a
s/on the context if/on the context of/
s/dummy/dumb/
Hi Kostas,
By mention "integration to be a follow up discussion" in FLIP-73 discussion
I think I'm more on the context if FLIP-74 because without including the
retrieval of JobClient in FLIP-74 we actually introduce a dummy public
interface.
1. return JobClient from Executor#execute actually has
Hi all,
Narrow the scope to FLIP-74 we aimed at introduce a useful and extensible
user-facing public interface JobClient. Let me reemphasize two major works
under this thread.
1. standard interface
As in FLIP-74 we introduce an interface JobClient with its methods, we'd
like to
make it a
Hi Konstantin,
* should we add "cancelWithSavepeoint" to a new public API, when we have
deprecated the corresponding REST API/CLI methods? In my understanding
there is no reason to use it anymore.
Good point. We can exclude "cancelWithSavepoint" from public API at least
for now,
since it is
Hi Thomas,
maybe there is a misunderstanding. There is no plan to deprecate anything
in the REST API in the process of introducing the JobClient API, and it
shouldn't.
Since "cancel with savepoint" was already deprecated in the REST API and
CLI, I am just raising the question whether to add it
I did not realize there was a plan to deprecate anything in the REST API?
The REST API is super important for tooling written in non JVM languages,
that does not include a Flink client (like FlinkK8sOperator). The REST API
should continue to support all job management operations, including job
Hi Zili,
thanks for working on this topic. Just read through the FLIP and I have two
questions:
* should we add "cancelWithSavepeoint" to a new public API, when we have
deprecated the corresponding REST API/CLI methods? In my understanding
there is no reason to use it anymore.
* should we call
Hi Flavio,
I agree that this would be good to have. But I also think that this is outside
the scope of FLIP-74, I think it is an orthogonal feature.
Best,
Aljoscha
> On 27. Sep 2019, at 10:31, Flavio Pompermaier wrote:
>
> Hi all,
> just a remark about the Flink REST APIs (and its client as
Hi all,
just a remark about the Flink REST APIs (and its client as well): almost
all the times we need a way to dynamically know which jobs are contained in
a jar file, and this could be exposed by the REST endpoint under
/jars/:jarid/entry-points (a simple way to implement this would be to check
modify
/we just shutdown the cluster on the exit of client that running inside
cluster/
to
we just shutdown the cluster on both the exit of client that running inside
cluster and the finish of job.
Since client is running inside cluster we can easily wait for the end of
two both in
About JobCluster
Actually I am not quite sure what we gains from DETACHED configuration on
cluster side.
We don't have a NON-DETACHED JobCluster in fact in our codebase, right?
It comes to me one major questions we have to answer first.
*What JobCluster conceptually is exactly*
Related
Thanks for your replies Kostas & Aljoscha!
Below are replies point by point.
1. For DETACHED mode, what I said there is about the DETACHED mode in
client side.
There are two configurations overload the item DETACHED[1].
In client side, it means whether or not client.submitJob is blocking to job
Hi Tison,
Thanks for the FLIP and launching the discussion!
As a first note, big +1 on providing/exposing a JobClient to the users!
Some points that would be nice to be clarified:
1) You mention that we can get rid of the DETACHED mode: I agree that
at a high level, given that everything will
Hi Tison,
Thanks for proposing the document! I had some comments on the document.
I think the only complex thing that we still need to figure out is how to get a
JobClient for a job that is already running. As you mentioned in the document.
Currently I’m thinking that its ok to add a method to
Hi all,
Summary from the discussion about introducing Flink JobClient API[1] we
draft FLIP-74[2] to
gather thoughts and towards a standard public user-facing interfaces.
This discussion thread aims at standardizing job level client API. But I'd
like to emphasize that
how to retrieve JobClient
20 matches
Mail list logo
