mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Nielsen <nik...@mesosphere.io>
Subject Re: Enabling 'network' namespace for custom network isolators
Date Mon, 11 May 2015 23:42:13 GMT
(inlined)

On 11 May 2015 at 14:30, Kapil Arya <kapil@mesosphere.io> wrote:

> On Mon, May 11, 2015 at 4:58 PM, Jie Yu <yujie.jay@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 <idownes@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?
>

We will be bringing in a dependency, experimental work with Calico, and
wanted to be flexible in how we call out to our tools.


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

No matter if you refactor the way we tell the launcher to set the namespace
flags, we need to refactor the way it is provided by the user to the slave.
(Don't get me wrong - I do love the decoupling of the slave flags from the
launcher :)

I suggested that we create 'namespaces/network' instead of the
--namespaces, which would be equivalent to the namespaces/pid
isolator+launcher code.

Thoughts?


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message