Hi Paul, +1 to what Alex/Tim say.
Maybe a (simple) example will help: a very basic "framework" I created recently, does away with the "Executor" and only uses the "Scheduler", sending a CommandInfo structure to Mesos' Agent node to execute. See: https://github.com/massenz/mongo_fw/blob/develop/src/mongo_scheduler.cpp#L124 If Python is more your thing, there are examples in the Mesos repository, or you can take a look at something I started recently to use the new (0.24) HTTP API (NOTE - this is still very much still WIP): https://github.com/massenz/zk-mesos/blob/develop/notebooks/HTTP%20API%20Tests.ipynb *Marco Massenzio* *Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>* On Fri, Aug 28, 2015 at 8:44 AM, Paul Bell <arach...@gmail.com> 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 <t...@mesosphere.io> 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 <a...@mesosphere.com> >> 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 <arach...@gmail.com> 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 >>>> >>> >>> >> >
