[
https://issues.apache.org/jira/browse/MESOS-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14137283#comment-14137283
]
Bernd Mathiske commented on MESOS-1384:
---------------------------------------
And here is a list of
Assumptions, design decisions, design goals, and explanations
------------------------------------------------------------------------------------
- Modules can be used by all constituents of Mesos, in particular slaves as
well as masters. Different sets of modules may or may not apply to either. Each
Mesos version of a module client program defines its own finite set of module
bindings, i.e. module injection points.
- Modules come packed in dynamic libraries (dynlibs).
- An installed module is a C++ object created by a call into a module
implementation in a dynlib. So far there is no well-defined set of features
that work or don’t work. However, we use a dynamic_cast with RTTI to verify
compatibility of a module with binding into Mesos. At a minimum, this restricts
Module types to abstract classes with at least one virtual function. In case
RTTI turns out not to be water-proof, we will eventually have to enumerate
features that do work. This still seems less tedious than breaking our very
simple API up into a much longer series of C-only constructs.
- A compiler version and flag check may become necessary.
- If really needed, an hourglass interface
(http://cppcon2014.sched.org/event/e659d8c088904f7a1540524b196afbe9#.VBiSd0sjMeE,
https://github.com/CppCon/CppCon2014/raw/master/Presentations/Hourglass%20Interfaces%20for%20C%2B%2B%20APIs%20-%20Stefanus%20Du%20Toit%20-%20CppCon%202014/Hourglass%20Interfaces%20for%20C%2B%2B%20APIs%20-%20Stefanus%20Du%20Toit%20-%20CppCon%202014.pdf)
can be added later, with an extra Mesos Module System version.
- Module installation has these phases: 1) Dynlib loading, 2) verification
including dependency checking, 3) instantiation, 4) binding (assignment to an
l-value that gets used somehow).
- All modules are named in one command line flag, which gets parsed early.
After all dynlibs have been loaded, all verification is run. Instantiation
happens later, in various places in Mesos, wherever modules are involved. This
is driven by other command line flags which then reference identifiers given by
the module flag. At first we only need to support a very simple naming scheme
where the module name is used directly and it is expected that there are never
conflicting module names. Example:
slave --modules=”/root/path1:module1,path2:module2” --allocator=”module1”
--auth=”module2”
- There can be multiple modules in a given dynlib. This allows shared
implementation and data elements and potential packaging convenience.
- Each dynlib must indicate what version of MMS it is built for. Then future
MMSs can determine whether to use a given pre-existing dynlib or not.
Conversely, an older Mesos/MMS can determine that a dynlib relies on a later
MMS version. This also serves as a handshake between Mesos and any arbitrary
dynlib to ensure it is dealing with a Mesos module dynlib at all.
- Once it is thus established that Mesos is dealing with a proper module dynlib
with a compatible version, the dynlib is trusted to behave cooperatively and
non-maliciously.
- Each dynlib indicates what minimum Mesos version it is compatible with.
- Each module indicates its “role”, e.g. Isolator, Allocator, Authenticator.
- There can be multiple modules for the same role in the same dynlib,
especially isolator modules.
- User code does not need to instantiate and bind all modules in a dynlib. It
can cherry-pick.
Limitations and Simplifications
----------------------------------------
- If you build a dynlib against a certain Mesos version, it will not be allowed
to be used with older Mesos versions. So for simplicity we bake the respective
Mesos version into the dynlibs.
- For each Role, a corresponding mesos version is kept in a table. If the role
changes in a non-compatible way, its version must be bumped by the responsible
Mesos developer to match the current mesos version.
- To use the module API, The module writer only faces a header file. Nothing
needs to be linked in for this purpose. However, to implement the specific
payload features of any given module, it may have to reference any number of
other parts of Mesos, including having to link against those.
- We consider corralling all Mesos features that are used by modules into a
facade layer. Thus backward compatibility could be maintained with more ease,
albeit at the cost of erecting the facade.
Things that we may want to support in the future and that should not be impeded
by the first MMS implementation
- Modules should be able to express and check interdependencies and mutual
compatibility.
- We do not check module versions beyond their type for now. In addition we
may want to give them a version number that gets bumped even if the type
remains the same, if the protocol for using the module changed.
> Add support for loadable MesosModule
> ------------------------------------
>
> Key: MESOS-1384
> URL: https://issues.apache.org/jira/browse/MESOS-1384
> Project: Mesos
> Issue Type: Improvement
> Affects Versions: 0.19.0
> Reporter: Timothy St. Clair
> Assignee: Niklas Quarfot Nielsen
>
> I think we should break this into multiple phases.
> -(1) Let's get the dynamic library loading via a "stout-ified" version of
> https://github.com/timothysc/tests/blob/master/plugin_modules/DynamicLibrary.h.
> -
> *DONE*
> (2) Use (1) to instantiate some classes in Mesos (like an Authenticator
> and/or isolator) from a dynamic library. This will give us some more
> experience with how we want to name the underlying library symbol, how we
> want to specify flags for finding the library, what types of validation we
> want when loading a library.
> *TARGET*
> (3) After doing (2) for one or two classes in Mesos I think we can formalize
> the approach in a "mesos-ified" version of
> https://github.com/timothysc/tests/blob/master/plugin_modules/MesosModule.h.
> *NEXT*
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
