Hi Paul, We don't [re]start a container since we assume once the task terminated the container is no longer reused. In Mesos to allow tasks to reuse the same executor and handle task logic accordingly people will opt to choose the custom executor route.
We're working on a way to keep your sandbox data beyond a container lifecycle, which is called persistent volumes. We haven't integrated that with Docker containerizer yet, so you'll have to wait to use that feature. You could also choose to implement a custom executor for now if you like. Tim On Fri, Aug 28, 2015 at 10:43 AM, Alex Rukletsov <[email protected]> wrote: > Paul, > > that component is called DockerContainerizer and it's part of Mesos Agent > (check "/Users/alex/Projects/mesos/src/slave/containerizer/docker.hpp"). > @Tim, could you answer the "docker start" vs. "docker run" question? > > On Fri, Aug 28, 2015 at 1:26 PM, Paul Bell <[email protected]> wrote: > >> Hi All, >> >> I first posted this to the Marathon list, but someone suggested I try it >> here. >> >> I'm still not sure what component (mesos-master, mesos-slave, marathon) >> generates the "docker run" command that launches containers on a slave >> node. I suppose that it's the framework executor (Marathon) on the slave >> that actually executes the "docker run", but I'm not sure. >> >> What I'm really after is whether or not we can cause the use of "docker >> start" rather than "docker run". >> >> At issue here is some persistent data inside >> /var/lib/docker/aufs/mnt/<CTR_ID>. "docker run" will by design (re)launch >> my application with a different CTR_ID effectively rendering that data >> inaccessible. But "docker start" will restart the container and its "old" >> data will still be there. >> >> Thanks. >> >> -Paul >> > >
