mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Chen <>
Subject Re: preparing a host on task launch event
Date Mon, 23 Feb 2015 08:48:47 GMT
Hi Michael,

If you're only launching docker containers, one possibility is to also use
the new powerstrips extension for Docker:

You can override default docker behaviors and do custom actions on the host
before a container is launched. Note this is not a production ready
solution as it's claimed on the github site.


On Sun, Feb 22, 2015 at 5:16 PM, Michael Neale <>

> Hi Adam - yes the hooks one possibly fit the bill - not entirely clear how
> to use it yet. The peristent one *should* work, but the problem for me
> isn't so much the management of volume, but the preparation of it (I have
> no need to make tasks sticky when the data can freely move around anyway).
> On Sun Feb 22 2015 at 8:04:58 PM Adam Bordelon <> wrote:
>> Michael, check out for
>> a recent feature to provide task launch hooks like you're asking about,
>> although it acts as a master/slave-specific library rather than a
>> task-specific prep step, so you'll have to customize the behavior based on
>> some information about the task.
>> Alternatively, you could use the upcoming Persistent Volumes feature (
>> in such a way that you
>> first launch a task to prep the state in a volume, and after its completion
>> launch the long-running docker task that uses that volume.
>> On Thu, Feb 19, 2015 at 6:45 PM, Michael Neale <>
>> wrote:
>>> (in a vain help to try and clarify) - I started with a similar pattern
>>> to what I have seen with redis - people ensure there is a redis on each
>>> host listening on a known port so apps can use it (by setting a unique
>>> constraint on host name, and then making sure number of instances == size
>>> of cluster). I started doing the same thing with a service that provides
>>> the volume data - this works great - but has to prepare the data *before*
>>> the docker container launches - or perhaps just as it is launching (docker
>>> can't see host mounts in bind mounts after it has launched - for boring
>>> reasons...).
>>> On Fri Feb 20 2015 at 1:38:20 PM Michael Neale <>
>>> wrote:
>>>> well not specifically talking about the mesos containerizer - it was
>>>> just something I tried. The main aim is to deploy containers that can be
>>>> bind mounted in a volume which is "prepared" on the host - the container
>>>> apps (docker apps) being deployed don't particularly care how that was
>>>> prepared - just that it was there. I was hoping for another task (or
>>>> something) that had run before had prepared it (in some cases it may simply
>>>> be rsyncing some data in place, in others, mounting a device - result is
>>>> the same - a volume/path can be provided to the docker container).
>>>> Does that make a little more sense ? (a bit hard to explain).
>>>> On Fri Feb 20 2015 at 1:23:46 PM Tim Chen <> wrote:
>>>>> Hi Michael,
>>>>> Can you elaborate how you use the Mesos containerizer to you prepare
>>>>> your host?
>>>>> In general hooks are exactly for this purpose, which is underway right
>>>>> now for defining the hooks in Mesos and also allowing it to be customized.
>>>>> Tim
>>>>> On Thu, Feb 19, 2015 at 6:18 PM, Michael Neale <
>>>>>> wrote:
>>>>>> I am currently using marathon and have a need to "prepare" the host
>>>>>> in some cases (currently looking at mounting a volume that the task
>>>>>> need - how that device is created is out of band BTW).
>>>>>> In theory this would be ideally done on some hook - but I am not
>>>>>> where (the hook would be called before the task proper is launched)
- it
>>>>>> could be simply as part of a task launch script if a plain command.
>>>>>> With the docker containerizer - I can actually use priv mode and
>>>>>> control the host (if I want) - but then I would like to have this
task run
>>>>>> separately to the main marathon long running task (as it has extra
>>>>>> which normally apps don't need) - I could bind mount in the docker
>>>>>> and launch a non priv container from within the mesos launched start
>>>>>> container ...
>>>>>> I can also use the default (?) mesos containerizer - which seems
>>>>>> let me run docker commands (ie bypassing the firstclass support in
>>>>>> for docker) but this "feels" like I am doing it wrong - is that wrong?
>>>>>> So in summary: is there a concept of a pre-launch step, and should
>>>>>> be working around the docker containerizer by using the mesos default
>>>>>> containerizer instead?
>>>>>> pointers appreciated.

View raw message