Hi Petr, can you go into technical detail about the disconnects? I wonder, our packages by default make ZK bind to 0.0.0.0 so even without a routable address I would think ZK should start up and handle the situation like any other network interruption, accept incoming connections and eventually retry to establish a connection to it's peers. What's the behaviour you're seeing?
Bit of background on the current setting: When we created the packages we had a lengthy pros/cons discussion whether to use network-online.target or not. Mesos works standalone without ZK. However we're also publishing Marathon packages which doesn't work without ZK. Meaning if we were to use network-online.target Devs could no longer use Marathon on their local system without an active Internet connection. That aside we also followed the systemd recommendation on https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ - network-online.target ... It is strongly recommended not to pull in this target too liberally: for example network server software should generally not pull this in (since server software generally is happy to accept local connections even before any routable network interface is up), it's primary purpose is network client software that cannot operate without network. Hope that explains our thinking. Best, -- Lukas On Wed, Mar 29, 2017 at 2:53 PM, Petr Novak <[email protected]> wrote: > Hello, > > I have used Mesosphere Zookeeper RPM and it uses After=network.target in > its zookeeper.service systemd unit file. This doesn’t guarantee that > Zookeeper service will start after network is available. To ensure this > After=network-online.target should be used. I spent some time with this > when Zookeeper was disconnected after reboots because of delays during > reboot on my VMs. If Centos starts up fast, which it typically does on a > clean install, it doesn’t manifest as a problem. Actually I have > experienced it on RHEL with some custom company layer on top which > introduced these delays. > > > > I would recommend to change it to avoid some bad user experience with slow > VMs. As well I think it is better for production. Or are there any reasons > why not? > > > > I used mesosphere-zookeeper.x86_64 3.4.6-0.1.20141204175332.centos7 > version. > > > > Regards, > > Petr > > > > >
