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

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: Communicate with a container while using Mesos unified container runtime

Thanks for all the ideas, I'll try dcos cli after upgrading mesos. On Fri, Mar 23, 2018 at 2:35 PM, Daemeon Reiydelle wrote: > For what I understand to be your use case, I will have queuing services > that the container queries for its next task. E.g. Kafka "queues" > > > >

Re: Communicate with a container while using Mesos unified container runtime

For what I understand to be your use case, I will have queuing services that the container queries for its next task. E.g. Kafka "queues" Please pardon typo's  ... sent from mobile Daemeonr@gmail.comUSA MOBILE: 415.501.0198 (California) Original message From: Gilbert Song

Re: Communicate with a container while using Mesos unified container runtime

No, this feature based on Container Attach/Exec , which was included starting from Mesos 1.2.0. I would recommend an upgrade to Mesos 1.4.1 or 1.3.2. On Thu, Mar 22, 2018 at 5:46 PM, Karan Pradhan wrote: > > > On

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: Mesos scalability

Hi Karan, Only one master can be elected leader in the current architecture. It's unlikely we're at a point where we need to balance work across masters to push scalability further. That comes with a lot of complexity, and we still have a lot of room for performance improvements on a single

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

Re: Mesos scalability

Karan to answer question 1. you can setup a DNS name with all of your masters in it and because of this https://github.com/apache/mesos/blob/master/docs/scheduler-http-api.md#master-detection the leading master will always be the one which ultimately handles the traffic.

Re: Mesos scalability

Even clustered, one must look at the specific event generating work loads, as well as monitoring the target systems for utilization. <==> "Who do you think made the first stone spear? The Asperger guy. If you get rid of the autism genetics, there would be no Silicon Valley" Temple Grandin