We can introduce a V2 API at any point while supporting V1.
Given that this has been the case for years I'm not entirely convinced
that the pain points are large enough to push anyone to pursue that.
( in particular, providing an _entire_ API and not just a few special
endpoints (which would
+1 nothing to add
@Austin It sounds reasonable. But this topic might deserve a dedicated
discussion thread, I think.
On Thu, Jul 20, 2023 at 12:52 AM Austin Cawley-Edwards <
austin.caw...@gmail.com> wrote:
> It doesn't need to be part of the Flink 2.0 release perse, but starting to
> wonder if
It doesn't need to be part of the Flink 2.0 release perse, but starting to
wonder if we'd get more bang for our buck if we started fresh with a v2
REST API vs. one-off cleanups of the current v1 API. @Chesnay Schepler
-- wdyt?
The v1 REST API seemed to grow naturally from its original use case
+1
On Wed, Jul 19, 2023 at 5:14 PM Jing Ge wrote:
> +1
>
> On Mon, Jul 17, 2023 at 5:30 AM Xintong Song
> wrote:
>
> > +1
> >
> > Best,
> >
> > Xintong
> >
> >
> >
> > On Thu, Jul 13, 2023 at 9:41 PM Chesnay Schepler
> > wrote:
> >
> > > Hello,
> > >
> > > The job cancellation REST endpoint
+1
On Mon, Jul 17, 2023 at 5:30 AM Xintong Song wrote:
> +1
>
> Best,
>
> Xintong
>
>
>
> On Thu, Jul 13, 2023 at 9:41 PM Chesnay Schepler
> wrote:
>
> > Hello,
> >
> > The job cancellation REST endpoint has a terminationMode query
> > parameter, which in the past could be set to either CANCEL
+1
Best,
Xintong
On Thu, Jul 13, 2023 at 9:41 PM Chesnay Schepler wrote:
> Hello,
>
> The job cancellation REST endpoint has a terminationMode query
> parameter, which in the past could be set to either CANCEL or STOP, but
> nowadays the job stop endpoint has subsumed the STOP
Hello,
The job cancellation REST endpoint has a terminationMode query
parameter, which in the past could be set to either CANCEL or STOP, but
nowadays the job stop endpoint has subsumed the STOP functionality.
Since then the cancel endpoint rejected requests that specified STOP.
I propose
