mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominic Hamon <>
Subject Re: Mesos Modules Design
Date Fri, 19 Sep 2014 20:03:52 GMT
I'm sorry, but I'm still having a hard time understanding why this needs to
be dynamic.

If the mesos core is split into modules that are built as standalone
libraries (static) then at link time the right combination of libraries can
be bundled together to create the end result. If you want to get even
smarter, we can have default versions that are linked in to the mesos core
as weak symbols so later linked libraries can override the defaults. This
may mean that we move to static linking across the board, but frankly there
are a few benefits to that approach.

With the approach as defined, does this mean that the default versions will
also have to be reimplemented as modules?

Has any effort been put into determining the performance overhead of the
approach as specified?

On Fri, Sep 19, 2014 at 11:35 AM, Niklas Nielsen <>

> Hi everyone,
> We have been iterating on a design for pluggable modules in Mesos lately
> and wanted to get a last round of feedback before putting out patch sets.
> Tim St Clair, Ben Hindman and I started the discussion (and work) on this
> subsystem and
> Kapil and Bernd took over the work (shepherded by Ben H and I) and have
> expanded on the original design to cope with api/modules/mesos versioning
> semantics and be extensible enough to cope future changes in the modules
> subsystem (dealing with modules dependencies, etc).
> The latest description of the modules system has been captured in:
> (for those of you who don't want to read through the JIRA threads).
> We have an implementation ready based on this design and will be sharing /
> starting review rounds start next week.
> Feel free to use this thread if you have any questions.
> Cheers,
> Niklas

Dominic Hamon | @mrdo | Twitter
*There are no bad ideas; only good ideas that go horribly wrong.*

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