[
https://issues.apache.org/jira/browse/MESOS-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14274372#comment-14274372
]
Kapil Arya commented on MESOS-2096:
-----------------------------------
Here are the required changes for our objective:
A) Expose some internal protobufs (by putting them in mesos.proto). Examples of
such protobufs include Modules, and any other protobufs needed by the files
being exposed (see B). Along with exposing said protobufs, we need to expose
the corresponding operators definitions that are not generated by the protobuf
compiler (i.e. definitions in common/type_utils.hpp).
B) Expose Isolator headers (slave/containerizer/isolator.hpp and
slave/state.hpp). Use mesos::slave for isolator.hpp and mesos::slave::state for
state.hpp. Isolator depends on slave/state.hpp and so we need to expose both.
This also requires us to disentangle these two files from the rest of the code.
C) Expose authentication headers. This is similar in spirit to B.
Next is a list of RRs that address A, B, and C.
A. Expose internal protobufs:
1. Moved Modules protobuf to mesos namespace by moving it into mesos.proto
(https://reviews.apache.org/r/29598/)
2. Moved Task and StatusUpdate from messages.proto to mesos.proto. (These
protobufs are used by the Isolator header)
(https://reviews.apache.org/r/29600/)
3. Moved authentication messages to mesos.proto.
(https://reviews.apache.org/r/29605)
4. Moved operators for internal protobufs to messages/messages.hpp. This
allows type_utils.hpp to only have operators corresponding to public protobufs
defined in mesos.proto.
(https://reviews.apache.org/r/2978)
5. Exposed type_utils.hpp as include/mesos/type_utils.hpp.
(https://reviews.apache.org/r/29781)
B. Expose Isolator headers:
6. Move mesos::internal::slave::state to mesos::slave::state.
(https://reviews.apache.org/r/29782)
7. Moved mesos::internal::slave::Isolator to mesos::slave namespace.
(https://reviews.apache.org/r/29602)
8. Exposed slave/containerizer/isolator.hpp and slave/state.hpp.
(https://reviews.apache.org/r/29603)
9. Exposed module/isolator.hpp for out-of-tree module building.
Review: https://reviews.apache.org/r/29604
C. Expose authentication headers
10. Exposed authentication headers.
(https://reviews.apache.org/r/29606)
> Allow Mesos modules to be built outside the Mesos source tree
> -------------------------------------------------------------
>
> Key: MESOS-2096
> URL: https://issues.apache.org/jira/browse/MESOS-2096
> Project: Mesos
> Issue Type: Bug
> Reporter: Kapil Arya
> Assignee: Kapil Arya
> Priority: Blocker
>
> We want to be able to provide a mechanism to allow third parties to build
> Mesos modules outside the Mesos source tree. Ideally, we would want to build
> Mesos modules without the need to build Mesos itself, provided that the
> public headers and corresponding shared libraries are available.
> Building a Mesos module requires access to the following components:
> 1. stout headers
> 2. libprocess headers and corresponding dynamic libraries (current, just
> libmesos.so)
> 3. protobufs
> 4. glog
> 5. boost
> Of the above components, stout headers and libprocess headers are already
> installed as part of standard Mesos installation.
> The problem lies with the bundled packages such as protobufs. It is the
> understanding that Mesos modules should be built with the same version of
> these packages with which Mesos was built. Since Mesos may have used the
> bundled versions, there is no way to build a module without having access to
> the Mesos source tree and the build directory.
> Having access to the source and build directory solves only part of the
> problem. The module build system needs to be aware of the configure
> parameters that were used for building Mesos (and accordingly, the bundled
> packages). A hackish solution is to force Mesos build system to emit the
> necessary information in a format that can be consumed by the module build
> system.
> A better solution is to remove the bundled packages -- protobuf, boost, and
> glog -- from the Mesos distribution and instead rely on system provided
> packages. Since these packages are usually available on most distros, we
> just need to do a configure check in Mesos and fail if they are not
> installed.
> Once these dependencies are resolved, we can export the header files defining
> module "kinds" such as isolator.hpp, authenticator.hpp, etc. At this point,
> there won't any known blockers that could prevent building modules out of
> Mesos tree.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
