Re: Release policy and 1.6 release schedule

I’m +1 for quarterly. Most importantly I want us to adhere to a predictable cadence. Sent from my phone > On Mar 23, 2018, at 9:21 PM, Jie Yu wrote: > > It's a burden for supporting multiple releases. > > 1.2 was released March, 2017 (1 year ago), and I know that some

Re: Release policy and 1.6 release schedule

> > 2) Backporting will be a burden if releases are too short. I think that in > practice, backporting will not take too much longer. If there was a > conflict back in the tree somewhere, then it's likely that after resolving > that conflict once, the same diff can be used to backport the change

Re: Release policy and 1.6 release schedule

It's a burden for supporting multiple releases. 1.2 was released March, 2017 (1 year ago), and I know that some users are still on that version 1.3 was released June, 2017 (9 months ago), and we're still maintaining it (still backport patches

Re: Support deadline for tasks

Ah, I was more curious about why they need to be killed after a timeout. E.g. After a particular deadline the work is useless (in Zhitao's case). On Fri, Mar 23, 2018 at 6:22 PM Sagar Sadashiv Patwardhan wrote: > Hi Benjamin, > We have a few tasks that

Re: Support deadline for tasks

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

Re: API review: max_duration on TaskInfo

In the interest of doing our due diligence, have you studied any prior art? For example, I was surprised to notice that htcondor doesn't really provide this as a first class thing: https://lists.cs.wisc.edu/archive/htcondor-users/2006- November/msg00024.shtml I didn't see it in any other systems

Re: Support deadline for tasks

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 wrote: > +1 > > This will be useful for us(Yelp) as well. > > On Fri, Mar 23, 2018 at 1:31 PM, Benjamin Mahler > wrote: >

Re: Support deadline for tasks

+1 This will be useful for us(Yelp) as well. On Fri, Mar 23, 2018 at 1:31 PM, Benjamin Mahler 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

API review: max_duration on TaskInfo

Hi everyone, I'd like to do an API review for MESOS-8725 . We are adding an optional `max_duration` to `TaskInfo` field. If a task does not terminate within this duration, built-in executors will kill the task with a new reason

Re: Support deadline for tasks

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

Re: Support deadline for tasks

> On Mar 23, 2018, at 9:57 AM, Renan DelValle 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

Re: Release policy and 1.6 release schedule

The best motivation I can think of for a shorter release cycle is this: if the release cadence is fast enough, then developers will be less likely to rush a feature into a release. I think this would be a real benefit, since rushing features in hurts stability. *However*, I'm not sure if every two

Re: Support deadline for tasks

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. -Renan On Fri, Mar 23, 2018 at 9:19 AM,

Re: Support deadline for tasks

Thanks James. I'll update the JIRA with our names and start with some prototype. On Thu, Mar 22, 2018 at 9:07 PM, James Peach wrote: > > > > On Mar 22, 2018, at 10:06 AM, Zhitao Li wrote: > > > > In our environment, we run a lot of batch jobs, some of