On Mon, May 11, 2015 at 4:29 PM, Ian Downes <idow...@twitter.com.invalid> wrote:
> > > > TLDR: We want to use a custom network isolator, but there is no way to > > enable the 'network' namespace from within an isolator module. > > > > > > We are working on creating a custom network isolator as a Mesos module. > > However, the way Mesos Slave is setup, there is no way to enable > 'network' > > namespace for the executor without enabling the 'port-mapping' isolator. > > This is due to the fact that the LinuxLauncher looks at the '--isolation' > > flag to figure out the list of namespaces to be enabled. The same problem > > would exist if one were to write a custom pid or filesystem isolation > > module. > > > > Curious, are these going to be open source and added to the codebase or > will they be proprietary modules? As of now, the custom isolator module is very much WIP as we are exploring the design space and so not sure if would be closed or open source. > What specifically is lacking in the > existing network and pid isolators? Could we extend those? > There is no pid isolator in works right now. I just used it as an example to describe the problem. The custom network isolator is pretty much useless without a network namespace :-). > So, there are a couple of question: > > > > 1. With the current Mesos source code, is there a way to specify the > > 'network/port_mapping' isolator in a way that it doesn't do the actual > work > > of mapping the ports (e.g., without specifying any port-mapping specific > > flags)? If this works, we can just specify this isolator on the slave > > command line and it would force the LinuxLauncher to create a new network > > namespace. > > > No, as written they're coupled. > > 2. Is it reasonable to have a separate mechanism to specify what namespaces > > should be created/enabled for an executor if we don't want to use the > > in-built isolators such as pid and port-mapping? > > > Yes. The simplest (cleanest?) way that I see would be to refactor the > launcher to take the desired flags when executing the executor, i.e., > (Linux)Launcher::fork() takes the namespace flags. The launcher would be > directed which namespaces to create by the caller, not inferring them > itself from any flags: the MesosContainerizer in turn would determine this > based on the isolators it was using for the container (querying them). This > also facilitates the MesosContainerizer having different isolators, and > thus namespaces, for different containers. > This is a good idea. WRT (2), one potential mechanism is to introduce a new flag, '--namespace'. > > The downside of creating such a low-level flag is that it provides little > > to no value to the end users. The end users shouldn't be concerned about > > which namespaces to enable and so on > > > That seems unduly onerous to the user and almost as rigid. > > > > Another alternative is to create a decorator hook for the LinuxLauncher, > > which can force the LinuxLauncher to enable certain namespaces without > > having to look at the '--isolation' flag. The downside here is that the > > decorator will be literally setting up a few bits and nothing more. > > > > I don't think there's a need for a decorator hook, just refactoring to pass > in through fork() is sufficient? > Agreed. > > Are there any other alternatives for a better and cleaner design (both long > > term and short term)? > > > > Happy to chat further about this. > > ian >
