Dick, I've also briefly skimmed at your original email to marathon mailing list and it sounded like executor sandboxes were not getting garbage collected (a mesos feature) when the slave work directory was rooted in /tmp vs /var? Did I understand that right? If yes, I would love to see some logs.
On Wed, Apr 30, 2014 at 1:51 PM, Tobias Knaup <t...@knaup.me> wrote: > In Marathon you can specify taskRateLimit (max number of tasks to start > per second) as part of your app definition. > > > On Wed, Apr 30, 2014 at 11:30 AM, Dick Davies <d...@hellooperator.net>wrote: > >> Managed to take out a mesos slave today with a typo while launching >> a marathon app, and wondered if there are throttles/limits that can be >> applied to repeated launches to limit the risk of such mistakes in the >> future. >> >> I started a thread on the marathon list >> ( >> https://groups.google.com/forum/?hl=en#!topic/marathon-framework/4iWLqTYTvgM >> ) >> >> [ TL:DR: marathon throws an app that will never deploy correctly at slaves >> until the disk fills with debris and the slave dies ] >> >> but I suppose this could be something available in mesos itself. >> >> I can't find a lot of advice about operational aspects of Mesos admin; >> could others here provide some good advice about their experience in >> preventing failed task deploys from causing trouble on their clusters? >> >> Thanks! >> > >
