You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Till Toenshoff <to...@me.com.INVALID> on 2018/09/12 01:14:48 UTC

Libevent bundling ahead.

Hey All,

We are considering bundling/vendoring libevent 2.0.22 with upcoming releases of Mesos.

Let me explain the motivation and then go into some details.

Due to https://issues.apache.org/jira/browse/MESOS-7076, SSL builds Mesos stopped functioning on distributions that offer libevent 2.1.8 by default. Specifically the failure was observed on Ubuntu 17/18 as well as on macOS. It has also just come to my attention that Fedora 18 shares the same fate. So the problem is less likely OS specific but more likely libevent + SSL + libprocess specific.
Instead of getting stuck in the rabbit hole of debugging right away, I decided that bundling a known good version of libevent was the most reliable way to prevent sad faces when building Mesos with SS but instead we can be sure SSL builds of Mesos function properly across all supported platforms, out of the box.

Details on the bundling;
We will include libevent 2.0.22 and we also include a patch that makes that version build against both openssl 1.0.x as well as 1.1.x. For unbundled builds (--with-libevent) I have some additional checks foreseen that try to prevent a build of a known bad variant of libevent + SSL + Mesos.

The bundling and those checks are a workaround, not a solution. I still am pursueing debugging the underlying cause. However, way too much time has passed already without a proper solution, hence this suggestion of a quick fix, bundling workaround.

Let me know your thoughts!

cheers,
Till


Re: Libevent bundling ahead.

Posted by James Peach <jp...@apache.org>.

> On Sep 11, 2018, at 6:14 PM, Till Toenshoff <to...@me.com> wrote:
> 
> Hey All,
> 
> We are considering bundling/vendoring libevent 2.0.22 with upcoming releases of Mesos.
> 
> Let me explain the motivation and then go into some details.
> 
> Due to https://issues.apache.org/jira/browse/MESOS-7076, SSL builds Mesos stopped functioning on distributions that offer libevent 2.1.8 by default. Specifically the failure was observed on Ubuntu 17/18 as well as on macOS. It has also just come to my attention that Fedora 18 shares the same fate.

F28

> So the problem is less likely OS specific but more likely libevent + SSL + libprocess specific.
> Instead of getting stuck in the rabbit hole of debugging right away, I decided that bundling a known good version of libevent was the most reliable way to prevent sad faces when building Mesos with SS but instead we can be sure SSL builds of Mesos function properly across all supported platforms, out of the box.
> 
> Details on the bundling;
> We will include libevent 2.0.22 and we also include a patch that makes that version build against both openssl 1.0.x as well as 1.1.x. For unbundled builds (--with-libevent) I have some additional checks foreseen that try to prevent a build of a known bad variant of libevent + SSL + Mesos.
> 
> The bundling and those checks are a workaround, not a solution. I still am pursueing debugging the underlying cause. However, way too much time has passed already without a proper solution, hence this suggestion of a quick fix, bundling workaround.
> 
> Let me know your thoughts!

I think this is OK as long as we have a reasonable expectation that we can unbundle soon-ish.

J

Re: Libevent bundling ahead.

Posted by James Peach <jp...@apache.org>.

> On Sep 11, 2018, at 6:14 PM, Till Toenshoff <to...@me.com> wrote:
> 
> Hey All,
> 
> We are considering bundling/vendoring libevent 2.0.22 with upcoming releases of Mesos.
> 
> Let me explain the motivation and then go into some details.
> 
> Due to https://issues.apache.org/jira/browse/MESOS-7076, SSL builds Mesos stopped functioning on distributions that offer libevent 2.1.8 by default. Specifically the failure was observed on Ubuntu 17/18 as well as on macOS. It has also just come to my attention that Fedora 18 shares the same fate.

F28

> So the problem is less likely OS specific but more likely libevent + SSL + libprocess specific.
> Instead of getting stuck in the rabbit hole of debugging right away, I decided that bundling a known good version of libevent was the most reliable way to prevent sad faces when building Mesos with SS but instead we can be sure SSL builds of Mesos function properly across all supported platforms, out of the box.
> 
> Details on the bundling;
> We will include libevent 2.0.22 and we also include a patch that makes that version build against both openssl 1.0.x as well as 1.1.x. For unbundled builds (--with-libevent) I have some additional checks foreseen that try to prevent a build of a known bad variant of libevent + SSL + Mesos.
> 
> The bundling and those checks are a workaround, not a solution. I still am pursueing debugging the underlying cause. However, way too much time has passed already without a proper solution, hence this suggestion of a quick fix, bundling workaround.
> 
> Let me know your thoughts!

I think this is OK as long as we have a reasonable expectation that we can unbundle soon-ish.

J