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
