, 2016 at 4:04 PM, Joshua Cohen <jco...@apache.org> wrote:
> Hi Aurorans[1],
>
> I'd like to call attention to an event the Compute group at Twitter is
> holding at the end of the month where there will be a few of
> Aurora/Mesos-related talks:
>
>
>1. David Robins
You can also see this error if the executor failed to launch the task for
some reason. If the issues Stephan describes above are not the root cause,
I'd recommend finding the task's directory (look at the mesos slave logs),
and then look for the executor logs to see if anything is out of the
Yes, there is, in fact, some more tuning to be done! The executor takes a
command line flag, --announcer-ensemble, which should be the host:port of
your ZK ensemble where tasks should be announced. You can configure the
flags passed to the executor when its launched via the
-thermos_executor_flags
Hi Tarun,
We recently moved to using a custom Vagrant basebox rather than installing
everything we need at provision-time to speed up the process of re-creating
the vagrant environment. The process for creating the basebox is still well
documented though, you can find details in the README here:
We run internally with -thermos_executor_cpu set to 0 (requiring task
owners to account for any executor CPU usage). This is generally safe, but
task owners should be notified that there's an outside chance they might
see CPU throttling that they were not previously seeing (assuming you're
using
It's C: batch_size is the number of instances that can be updated at a
given time.
There's no direct relation between batch size and total number of
shards/instances. E.g. for a job with 100 instances and a batch size of 10,
at most 10 instances will be updating at a given time. If it turns out
