mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Wu <>
Subject Re: DC/OS (Mesos) portability
Date Fri, 03 Nov 2017 19:54:05 GMT
It isn't clear to me how DC/OS would benefit from (ongoing) work to
create/push Mesos packages.  DC/OS downloads and builds all of its
component parts from source.

Also, we (Mesos devs) are hoping to get more frameworks to move away from
using libmesos (including the API shims), in favor of using the HTTP APIs
instead.  So we have a dis-incentive to provide a libmesos bundle.

On Fri, Nov 3, 2017 at 8:23 AM, Tomas Barton <> wrote:

> Hi,
> I'd like to contribute to DC/OS with a Debian/Suse/... support.
> Surprisingly on Debian most of the compatibility issues could be solved by
> a sequence of symlinks.
> Why Mesos dev list? :)
> Currently the biggest issue is connected to distributing libmesos-bundle
> tar archive, which contain the library and several others. The
> library is dynamically linked with certain libcurl,  libssl, libsvn etc.
> that might differ between distributions.
> I can think of a few solutions:
>  1. Compile Mesos (master and agent) using static build (which as I
> understood aren't currently fully supported/propagated).
>  2. Generate bundle during automatic builds for certain supported
> distributions.
>  3. Include libmesos in standard distribution channels - rpm, deb packages
> (that might take same time).
> The last solution would be the best, but Mesos release cycle is very
> different from distributions release cycle. It might be complicated to
> synchronize.
> I coudn't find scripts for generating libmesos-bundle, but it's a archive
> with libraries from build server, e.g.
> bundle-1.10-1.4-63e0814.tar.gz
> (32MB).
> So the question is, whether Mesos website could provide prebuild libmesos
> bundle for each release and platform, that could be afterwards used e.g. in
> DC/OS packages?
> Last issue might be connected to an executor that eventually might need OS
> family ENV variable with OS release version, so that it can fetch
> corresponding libbundle archive. Such information is typically parsed from
> `uname -a` or `lsb_release -sri` (if available). This way DC/OS could be
> running on a cluster with diverse OS versions/distributions.
> Thanks for your time! I'd like to hear your opinion.
> Regards,
> Tomas Barton

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message