mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Petr <tp...@hubspot.com>
Subject Re: Exposing executor container
Date Tue, 12 Aug 2014 17:45:34 GMT
Hey Vinod,

We're not using mesos-fetcher to download the executor -- we ensure our
executor exists on the slaves beforehand (during machine provisioning, to
be exact). The issue that Whitney is talking about is OOMing while fetching
artifacts necessary for task execution (like the JAR for a web service).

Our own executor
<https://github.com/HubSpot/Singularity/tree/master/SingularityExecutor> has
some nice enhancements around S3 downloads and artifact caching that we
don't necessarily want to lose if we switched back to using mesos-fetcher.

Surfacing the container ID seems like a trivial change, but another
alternative could be to allow frameworks to specify an alternative fetcher
executable (perhaps in CommandInfo?).

Thanks,
Tom


On Tue, Aug 12, 2014 at 1:09 PM, Vinod Kone <vinodkone@gmail.com> wrote:

> Hi Whitney,
>
> While we could conceivably set the container id in the environment of the
> executor, I would like to understand the problem you are facing.
>
> The fetching and extracting of the executor is done in by mesos-fetcher, a
> process forked by slave and run under slave's cgroup. AFAICT, this
> shouldn't cause an OOM in the executor. Does your executor do more
> fetches/extracts once it is launched (e.g., for user's tasks)?
>

Mime
View raw message