On Mon, May 11, 2015 at 4:58 PM, Jie Yu <yujie....@gmail.com> wrote: > > > > 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. > > > +1 > > For instance, the isolator could have an interface 'int namespaces()' which > specifies the namespaces needed. The launcher can just query that and pass > them to the linux launcher. > > Since currently, the launcher and isolator interfaces are designed for both > mac and linux and namespace does not make sense on Mac, we probably need a > LinuxIsolator interface (inherit from Isolator) and a LinuxLauncher > interface (inherit from Launcher). >
This is a good idea. I think this will keep things pretty clean and readable within Mesos and for the Isolators. > - Jie > > On Mon, May 11, 2015 at 1: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? What specifically is lacking in the > > existing network and pid isolators? Could we extend those? > > > > 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. > > > > 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? > > > > Are there any other alternatives for a better and cleaner design (both > long > > > term and short term)? > > > > > > > Happy to chat further about this. > > > > ian > > >
