Heh, that's a tricky one : ). A framework indeed consists of a scheduler and an executor, both are mandatory. But Mesos provides a default general-purpose executor, which can be used by frameworks. This executor has many names, two most common are "MesosExecutor" and "CommandExecutor". Marathon doesn't have its own executor (in contrast to, say, Aurora) yet, it uses CommandExecutor for all of its tasks.
CommandExecutor is implicitly created by Mesos if a task specification do not include executor. This executor can have just a single task and is garbage collected after the task finishes. A task is any command, which will be executed via '/bin/sh -c <command>'. On Fri, Aug 28, 2015 at 8:50 PM, Tim Chen <[email protected]> wrote: > We have primitives for persistent volumes in next release (0.25.0) but > DockerContainerizer integration will happen most likely the version after. > > Tim > > On Fri, Aug 28, 2015 at 11:50 AM, Tim Chen <[email protected]> wrote: > >> Hi Paul, >> >> Alternatively you can try to launch your task on the same host by >> specifying a constraint with marathon and mount a directory on the host in >> your container everytime to work-around as well. >> >> Tim >> >> On Fri, Aug 28, 2015 at 11:44 AM, Paul Bell <[email protected]> wrote: >> >>> Alex & Tim, >>> >>> Thank you both; most helpful. >>> >>> Alex, can you dispel my confusion on this point: I keep reading that a >>> "framework" in Mesos (e.g., Marathon) consists of a scheduler and an >>> executor. This reference to "executor" made me think that Marathon must >>> have *some* kind of presence on the slave node. But the more familiar I >>> become with Mesos the less likely this seems to me. So, what does it mean >>> to talk about the Marathon framework "executor"? >>> >>> Tim, I did come up with a simple work-around that involves re-copying >>> the needed file into the container each time the application is started. >>> For reasons unknown, this file is not kept in a location that would readily >>> lend itself to my use of persistent storage (Docker -v). That said, I am >>> keenly interested in learning how to write both custom executors & >>> schedulers. Any sense for what release of Mesos will see "persistent >>> volumes"? >>> >>> Thanks again, gents. >>> >>> -Paul >>> >>> >>> >>> On Fri, Aug 28, 2015 at 2:26 PM, Tim Chen <[email protected]> wrote: >>> >>>> 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 >>>>>> >>>>> >>>>> >>>> >>> >> >
