This is meant as a guide for Mesos Module users and developers.

Use and development of Mesos Modules is at own risk! Only graced modules are maintained by the Mesos project.

Please direct all questions to the relevant module writer and/or write to Questions related to modules sent to user and dev list will be redirected to the modules list.

This document is still work in progress. Stay tuned.


Mesos Modules is a process for dynamic library writing and loading, making it easy to extend inner workings of Mesos.
This is a powerful feature, as we get even more extensible and flexible ways of setting up Mesos - but also for isolating dependencies and complexity in external libraries and to ease experimentation with new features.
For example, imagine a loadable allocators which contains a VM (Lua, Python, ...) which makes it possible to try out new allocator algorithms without forcing those dependencies into the project.

Getting started

Using a Mesos Module

How Mesos Modules work

Developing a Mesos Module


The HelloWorld module

#include <iostream>
#include "test_module.hpp"

// TODO(nnielsen): Add new struct registration.
class TestModuleImpl : public TestModule
    std::cout << "HelloWorld!" << std::endl;
  virtual int foo(char a, long b)
    return a + b;

  virtual int bar(float a, double b)
    return a * b;
TestModule* create()
	return new TestModule();


Building a module

$ g++ -lmesos -fpic -o test_module.o test_module.cpp
$ gcc -shared -o test_module.o

TODO(nnielsen): Provide Makefiles to ease the above and wire up test integration.

Testing a module

Work in progress: MESOS-1864

Developing Isolator Modules

Developing Authenticator Modules

Developing Containerizer Modules

Developing Allocator Modules

Module Naming Conventions

When modules have been loaded, there only identifier is their name. If more than one module has the same name, only the last loaded one will be effective.

Therefore, we encourage module writers to name their modules (

For example:

Module NameModule Domain nameModule Symbol Name



In short:

  • Keep case of module name.
  • Lower case and reverse domain
  • Separate with underscore

Module Versioning and backwards compatibility

Before loading the above module, a dynamic library that contains the module needs to be loaded into Mesos. This happens early in Mesos startup code. The Mesos developer does not need to touch that code when introducing new module roles.
However, the developer is responsible for registering what versions of any given module are expected to remain compatible with Mesos as it progresses. This information is maintained in a table in src/module/module_manager.cpp. It contains an entry for every possible module role that Mesos recognizes, each with a corresponding Mesos release version number. This number needs to be adjusted by the Mesos developer to reflect the current Mesos version whenever compatibility between Mesos and modules that get compiled against it gets broken. Given that module implementation for older Mesos versions can still be written in the future, this may be impossible to tell and so in doubt it is best to just bump the required module version to the current Mesos version. But if one can be reasonably sure, assuming cooperative module developers, that a certain kind of module will continue to function across several Mesos versions, the table provides an easy way to specify this.


MesosRole versionLibraryIs module loadableReason 

0.29.0 compiled against a newer Mesos release. older than the role version supported by Mesos. older than the role version supported by Mesos.


The summarize, for successfully loading the module, the following relationship must exist between the various versions:

Role version <= Library version <= Mesos version



Mesos versionMesos releases 
Module API versionBumped when the module management system changes 
RoleThe purpose that a module fulfills.In a given Mesos implementation this is tied to a specific object type, e.g. “Allocator”, “Isolator”, “Authenticator”.
  • No labels