IPv6 progress / Default listening socket

[Evers Benno <be...@yandex-team.ru>]

Hi all,

sorry in advance for the wall of text below :)

I went ahead and implemented a proof-of-concept, and things seem to work
quite well so far: I have a mesos-master and a mesos-slave on different
machines in an IPv6-only network, and I'm able run RENDLER jobs on them.

The one unexpected issue that came up, and which was a bit messy to deal
with, was how to select the default listening socket for libprocess
(__s__ in process.cpp/initialize()).

Previously, it was set to 0.0.0.0:0, which doesn't accept incoming IPv6
connections.

The most conservative approach would be to introduce some environment
variable like `LIBPROCESS_ENABLE_IPV6`, which causes the default to be
[::]:0 and otherwise it will stay 0.0.0.0.

Of course, the downside is to have one additional bit of global state, a
lot of dead code (since no current user of mesos *needs* to enable IPv6,
most probably wont), and the fact that users have to care about the
transport protocol used, even if they just want to specify a hostname.
Also, it would imply that this doesn't work out of the box:

  `rendler --master=[2001:6b8::1]:5005`

A bolder possibility would be to set the new default to [::]:0 and add
support for IPV6_V6ONLY as a requirement for running mesos (it is
already required by POSIX, so it wouldn't have a huge impact). This is
certainly the easiest to implement and probably also the cleanest, but
it would risk breaking stuff on nodes with a broken IPv6 setup. I don't
know how common this is.

Finally, one could attempt a compromise, by using an algorithm such as

 - If the host system supports turning off IPV6_V6ONLY, listen for
   both address families on ::
 - Else, if there is a non-loopback IPv4 configured for `hostname()`,
   bind to 0.0.0.0
 - Else, if there is a non-loopback and non-link-scope IPv6 configured,
   bind to :: (for ipv6-only hosts on non-dual-stack nodes)
 - Else, bind to 0.0.0.0 (to preserve backwards-compatibility in case
   we can't make an educated guess)

But of course the problem here is that this algorithm seems pretty
arbitrary, although I don't see any obvious case where it would fail.

Personally, I feel like it's less a technical issue and more a matter of
"project philosophy" to decide which of these directions (or maybe
something else entirely) would be suited best for mesos.


As side note, I separated some of the patches to stout that are
independent of any architectural decisions, and created issue MESOS-4606
for them and I'm looking to find a shepherd for this.

I'm not sure that I completely understand the procedure. It seems that I
need a reviewer before I can publish the review, but I assume a
potential reviewer would prefer to see the code before he decides if he
wants to invest the time?

Any comments and thoughts are of course always welcome.

Best,
Benno