This is meant as a guide for Mesos Module users and developers.
Info |
---|
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 modules@mesos.apache.org. Questions related to modules sent to user and dev list will be redirected to the modules list. |
Info |
---|
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
Dependencies
The HelloWorld module
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
#include <iostream> #include "test_module.hpp" // TODO(nnielsen): Add new struct registration. class TestModuleImpl : public TestModule { public: TestModuleImpl() { 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
Code Block | ||
---|---|---|
| ||
$ g++ -lmesos -fpic -o test_module.o test_module.cpp $ gcc -shared -o libtest_module.so 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 (http://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html).
For example:
Module Name | Module Domain name | Module Symbol Name |
---|---|---|
foobar | mesos.apache.org | org_apache_mesos_foobar |
barBaz | example.com | com_example_barBaz |
In short:
- Keep case of module name.
- Lower case and reverse domain
- Separate with underscore
Module Versioning and backwards compatibility
Mesos | Role version | Library | Is module loadable | Reason | ||||||
---|---|---|---|---|---|---|---|---|---|---|
0.18.0 | 0.18.0 | 0.18.0 |
| |||||||
0.29.0 | 0.18.0 | 0.18.0 |
| |||||||
0.29.0 | 0.18.0 | 0.21.0 |
| |||||||
0.18.0 | 0.18.0 | 0.29.0 |
| Library compiled against a newer Mesos release. | ||||||
0.29.0 | 0.21.0 | 0.18.0 |
| Module/Library older than the role version supported by Mesos. | ||||||
0.29.0 | 0.29.0 | 0.18.0 |
| Module/Library 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
Appendix
Definitions
Term | Definition | Example |
---|---|---|
Mesos version | Mesos releases | |
Module API version | Bumped when the module management system changes | |
Role | The purpose that a module fulfills. | In a given Mesos implementation this is tied to a specific object type, e.g. “Allocator”, “Isolator”, “Authenticator”. |