(1) is something that has come up before. The containerizer deals with a variable sized container, the semantics of a task are defined by the executor, there is no way for the containerizer to understand the meaning of a task currently. Some tasks are "special" in that they don't have an executor (e.g. command task, docker task, etc), and in this case they will be isolated individually. The main approach that has been discussed to my knowledge is to have the executor leverage the mesos containerizer to create nested containers: https://issues.apache.org/jira/browse/MESOS-3333
For (2) you should implement a custom network _isolator_ that the mesos containerizer can use. With respect to (3), for regular resources the policy used in Mesos is that Mesos will never make decisions to kill things, it must be triggered by the framework or an operator. So this requirement should be met already. For revocable resources, Mesos may destroy containers, but the framework will be aware of that when deciding to use them. If they are stateful, you should use reservations and store the data in a volume. You can mix containerizers, although they should not conflict with each other. On Fri, Oct 9, 2015 at 3:04 AM, Alex Glikson <glik...@il.ibm.com> wrote: > Triggered by the thread on potential deprecation of external > containerizer, I wonder what would make sense to do to address the > following set of requirements: > 1. I need resource isolation for individual tasks (mainly for QoS > reasons), so having container per task seems reasonable > 2. I have rather advanced networking requirements, not easily addressable > with default mesos containerizer or docker > 3. Some of the tasks are stateful, so I would really prefer that Mesos > doesn't kill them, pretty much ever (unless triggered by the framework) > > It seems that having my own containerizer would be a reasonable approach. > But given some of the requirements above, I am trying to figure out > whether I would at all need to implement "usage" and "update" (and maybe > even 'destroy', unless it is invoked as part of killTask received from the > framework?). > > Moreover, the isolation mechanism I have in mind does use the same Linux > features as docker/mesos containerizers (cgroups, namespaces, etc), but in > a somewhat different manner. So, I wonder whether I can use more than one > containerizer on the same host -- e.g., to run tasks of my framework on > the same host as tasks of , say, Marathon+docker (and if yes, how can I > check whether they will work together). If mixing containerizers in the > same host is not recommended, is there an easy way to dynamically decide > which slaves are 'allocated' to which 'type' of resources (e.g., some sort > of entire-host allocation policy)? > > Some thoughts/advice would be really helpful, before we actually spend > time implementing a new containerizer, one way or another. > > Thanks! > Alex > > P.S. Disclaimer: I am new to Mesos, so maybe some (or all) of the above > doesn't make much sense, so bear with me.. > > >
