Hi,

there ain't much differences between Debian stable and Ubuntu LTS. Ubuntu
18.04 should be pretty much the same as Debian 9 (as far as Mesos
dependencies concerned).

Currently in DC/OS if you install a framework such as Elastic it will fetch
incorrect libmesos-bundle (built for CentOS 7). libmesos-1.4.0.so will be
dynamically linked to libssl.so.1.0.0 while in Debian 9 there's
libssl.so.1.0.2. Similar problem for libcurl and few others. If DC/OS
wouldn't bundle libcurl and simply require appropriate distribution package
during installation, there wouldn't be any compatibility issue. Or is there
a need for using different curl versions in each DC/OS package?

DC/OS 1.11 will no longer overwrite LD_LIBRARY_PATH in Mesos executor,
which eliminates one of current issues (Thx Alex!)

In fact if libmesos would be loaded from system path instead of fetching a
resource from an URI during task deployment we wouldn't need to include
libmesos in the library bundle at all.

I think we can move to discussion to an approprite DC/OS ticket and resolve
issues on DC/OS side first, then come back to Mesos if necessary.

Probably https://jira.mesosphere.com/browse/DCOS_OSS-25 ?

Tomas

On 22 November 2017 at 00:01, Alex Rukletsov <a...@mesosphere.com> wrote:

> I think Tomas means Mesos dependencies, like libcurl, and not libmesos. If
> I understand him correctly, he is saying that part of Mesos dependencies is
> not distributed with Mesos binaries, and, if not included into a
> distribution, might complicate installation process.
>
> On Fri, Nov 3, 2017 at 8:54 PM, Joseph Wu <jos...@mesosphere.io> wrote:
>
> > 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 <barton.to...@gmail.com>
> > 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 libmesos.so 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.
> > > https://downloads.mesosphere.io/libmesos-bundle/libmesos-
> > > 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
> > >
> >
>

Reply via email to