Hi Benjamin,
We have a few tasks that should be killed after
some timeout. We currently have some logic in our scheduler to kill these
tasks. Would be nice to delegate this to the executor.
- Sagar
On Fri, Mar 23, 2018 at 3:29 PM, Benjamin Mahler <bmah...@apache.org> wrote:
> Sagar, could you share your use case? Or is it exactly the same as
> Zhitao's?
>
> On Fri, Mar 23, 2018 at 3:15 PM, Sagar Sadashiv Patwardhan <
> sag...@yelp.com>
> wrote:
>
> > +1
> >
> > This will be useful for us(Yelp) as well.
> >
> > On Fri, Mar 23, 2018 at 1:31 PM, Benjamin Mahler <bmah...@apache.org>
> > wrote:
> >
> > > Also, it's advantageous for mesos to be aware of a hard deadline when
> it
> > > comes to resource allocation. We know that some resources will free up
> > and
> > > can make better decisions when it comes to pre-emption, for example.
> > > Currently, mesos doesn't know if a task will run forever or will run to
> > > completion.
> > >
> > > On Fri, Mar 23, 2018 at 10:07 AM, James Peach <jpe...@apache.org>
> wrote:
> > >
> > > >
> > > >
> > > > > On Mar 23, 2018, at 9:57 AM, Renan DelValle <
> > renanidelva...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Hi Zhitao,
> > > > >
> > > > > Since this is something that could potentially be handled by the
> > > > executor and/or framework, I was wondering if you could speak to the
> > > > advantages of making this a TaskInfo primitive vs having the executor
> > (or
> > > > even the framework) handle it.
> > > >
> > > > There's some discussion around this on https://issues.apache.org/
> > > > jira/browse/MESOS-8725.
> > > >
> > > > My take is that delegating too much to the scheduler makes schedulers
> > > > harder to write and exacerbates the complexity of the system. If 4
> > > > different schedulers implement this feature, operators are likely to
> > need
> > > > to understand 4 different ways of doing the same thing, which would
> be
> > > > unfortunate.
> > > >
> > > > J
> > >
> >
>
