mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kapil Arya (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MESOS-2096) Allow Mesos modules to be built outside the Mesos source tree
Date Mon, 12 Jan 2015 23:08:34 GMT

    [ 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)

Mime
View raw message