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..
