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 <[email protected]> wrote: > Michael, check out https://issues.apache.org/jira/browse/MESOS-2060 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 ( > https://issues.apache.org/jira/browse/MESOS-1554) 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected] >>>> > 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 may 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 sure >>>>> 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 access >>>>> which normally apps don't need) - I could bind mount in the docker socket >>>>> and launch a non priv container from within the mesos launched start >>>>> container ... >>>>> >>>>> I can also use the default (?) mesos containerizer - which seems to >>>>> let me run docker commands (ie bypassing the firstclass support in mesos >>>>> 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 I >>>>> be working around the docker containerizer by using the mesos default >>>>> containerizer instead? >>>>> >>>>> pointers appreciated. >>>>> >>>> >>>> >
