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 > > >
