mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kone <vinodk...@apache.org>
Subject Re: Some initial thoughts on IPv6
Date Tue, 02 Feb 2016 19:21:01 GMT
Thanks for starting the discussion about this Evers! Supporting IPv6 has
been a long awaited feature for Mesos, so glad to see that you are
interested in working on this.

I would also vote for #1 because it seems to get us far with minimal code
changes. There is already a #networking working group
<https://cwiki.apache.org/confluence/display/MESOS/Apache+Mesos+Working+Groups>
that you might leverage to get feedback (of course you can always post here
on the dev list too).

@Kapil is this something you want to shepherd?

On Mon, Feb 1, 2016 at 11:35 PM, Vetoshkin Nikita <
nikita.vetoshkin@gmail.com> wrote:

> All thumbs up for (1).
> I think supporting several IP addresses (and thus sockets) can be tricky to
> implement in libprocess and will require some machinery for setting things
> up and tearing down (what if only one bind() of N will succeed, etc.). It
> may also make debugging stuff harder (e.g. firewalls, routes, etc can
> result in user complains like "I can successfully connect from this host,
> but not this one").
> Not sure though if we need to support (set) IPV6_V6ONLY flag (man 7 ipv6).
> I'm a bit worried about MasterInfo.ip attribute. How "deprecated" it is.
> Did currently existing frameworks/language bindings already abandon it?
>
> On Mon, Feb 1, 2016 at 1:27 AM Evers Benno <bennoe@yandex-team.ru> wrote:
>
> > Hi all,
> >
> > after looking through the mesos source code for a while, here are
> > some of my initial thoughts.
> >
> > There seem to be at least two issues that can be tackled separately:
> >  - Communication between mesos daemons over the network
> >  - Communication in and out of containers when using network isolation
> >
> > Having the first one would already be valuable for installations that
> > don't use network isolation, so I'll focus on this for now.
> >
> > If a mesos master daemon runs on say mesos-master.example.org:5050, and
> > this host has both A and AAAA addresses configured it seems to be
> > desirable that slaves can communicate with this node over both IPv4 and
> > IPv6, depending on their own capabilities.
> >
> > From the client perspective, the problem is solved by the "Happy
> > Eyeballs" algorithm, i.e. trying both possibilities and using
> > the one where it is possible to connect. The only complication is that
> > address resolution should probably be delayed until we actually want to
> > connect, to avoid spurious failures.
> >
> > On the server side it is a bit more subtle, since the server has to
> > decide which address it should bind its listening socket to. Some
> > possibilities would be:
> >
> >  1) Do nothing special, just bind to the address that was specified
> >  2) Allow specifying multiple listen IP's
> >  3) Allow to specify a network interface and port and open two separate
> > listening sockets for IPv4 and IPv6
> >
> > These are not mutually exclusive.
> >
> > It seems that (2) and (3) would be desirable anyways, since they would
> > also enable running on hosts with multiple network interfaces.
> >
> > It is however worth noting that (1) already gets us quite far without
> > changing the assumption that there is a single IP associated to a mesos
> > daemon: If an IPv4 address is specified, things will work the same as
> > before, and if there is an IPv6 address specified it will by default
> > accept connections from both IPv4 and IPv6 sources. This behaviour can
> > even be changed at system-level, if not desired. (via
> > /proc/sys/net/ipv6/bindv6only, or the mac/windows equivalent).
> >
> > So, tl;dr: I believe a lot of of useful progress could already be
> > achieved by a relatively small patch series, that:
> >
> >  - Fills in the blanks in stout's net:IP, and gives all functions
> >    which  take an explicit "family"-argument a default value of
> >    AF_UNSPEC
> >  - Updates the IPv4-specific parts in libprocess (in particular, the
> >    parsing of IP literals in URL strings and the constructor
> >    Socket::create(Kind, Option<int> fd), which should probably be split
> >    into e.g. Socket::make(sa_family_t, Kind) and
> >    Socket::wrap(int fd, Kind))
> >  - Changes all calling sites to use the new functions
> >
> > The protobuf IPC format doesn't seem to require any changes, since the
> > only IPv4-dependent field (MasterInfo.ip) was already deprecated in
> 0.24.0.
> >
> > After this, the next step would then be to look at network isolation and
> > enabling communication in and out of containers.
> >
> > Thoughts? Comments? Am I missing something?
> >
> > Best regards,
> > Benno
> >
>

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