+++ This bug was initially created as a clone of Bug #1347329 +++ Description of problem: a two node glusterfs seems not possible anymore?! Version-Release number of selected component (if applicable): 3.7-11, 3.8 How reproducible: set: cluster.quorum-type: fixed cluster.quorum-count: 1 cluster.server-quorum-type: none Steps to Reproduce: 1. Shutdown (kill) other node glusterd/glusterfs 2. Check: gluster volume start nfs-storage 3. Get error like bellow. Actual results: volume start: nfs-storage: failed: Quorum not met. Volume operation not allowed. Expected results: Running bricks on one node. Additional info: Latest Debian Jessie --- Additional comment from Joe Julian on 2016-06-16 15:37:19 EDT --- With a 2 server replica 2 started volume - no other volumes: Without any quorum settings being set, the brick will not start on boot if the other server is down. This is a departure from prior behavior and cannot be worked around. Setting cluster.server-quorum-type to none does not allow the brick to be started by glusterd. It looks like as long as glusterd_is_any_volume_in_server_quorum returns gf_false it should. In my test case there was only one volume and as long as no volumes are set to "server" that function should return gf_false. If cluster.server-quorum-type is set to server and cluster-server-quorum-ratio is set to 0, the brick will start, but neither nfs nor glustershd start. --- Additional comment from Atin Mukherjee on 2016-06-21 08:11:56 EDT --- Is there any specific reason why are we considering quorum tunables with a two node set up? Ideally we should consider the quorum options in case of at least three node set up. Also as Joe pointed out on a two node set up, if one of the node goes for a reboot while the other is down, the daemons do not get spawned as data consistency is not guaranteed here. The moment the peer update is received the daemons are spawned. IMO, this is an expected behaviour as per the design. I am closing this bug, please feel free to reopen if you think otherwise. --- Additional comment from Jules on 2016-06-21 08:19:21 EDT --- So what are the switches "none" for if they doesn't function? --- Additional comment from Atin Mukherjee on 2016-06-21 08:23:11 EDT --- (In reply to Jules from comment #3) > So what are the switches "none" for if they doesn't function? That's the default value. If you don't set server quorum type to server, its basically considered to be off and that's what it implies here. --- Additional comment from Jules on 2016-06-21 08:26:35 EDT --- Have you tested the second part that JoeJulian mentioned? --- Additional comment from Atin Mukherjee on 2016-06-21 08:55:59 EDT --- "If cluster.server-quorum-type is set to server and cluster-server-quorum-ratio is set to 0, the brick will start, but neither nfs nor glustershd start." - is this valid for a set up having more than 2 nodes? Anyways, I will test this and get back. --- Additional comment from Atin Mukherjee on 2016-06-22 01:49:43 EDT --- I tested the same with a three node set up and bricks don't come up in that case. As I mentioned earlier, that having quorum tunables with a 2 node setup doesn't make sense to me, I'd not consider it as a bug. --- Additional comment from Joe Julian on 2016-06-22 03:02:31 EDT --- It breaks prior production behavior with no workaround and should thus be considered a bug. If you want to protect users from themselves by default, I'm all behind this, but if a user knows the risks and wishes to override the safety defaults to retain prior behavior, this should be allowed. --- Additional comment from Atin Mukherjee on 2016-06-22 03:06:05 EDT --- Well, you always have an option to use volume start force as a work around in this case, isn't it? --- Additional comment from Jules on 2016-07-02 05:15:56 EDT --- (In reply to Atin Mukherjee from comment #9) > Well, you always have an option to use volume start force as a work around > in this case, isn't it? Well, since this needs to be done by manual intervention this is not a good work around i recommend. How about a new config switch to get this working without using the force option like it was in the past. As Joe Julian mentioned. A user which knows the risks should be able to override the safety defaults.
REVIEW: http://review.gluster.org/14848 (glusterd: spawn daemons from init() on a single or two node setup) posted (#1) for review on master by Atin Mukherjee (amukherj)
REVIEW: http://review.gluster.org/14848 (glusterd: spawn daemons from init() on a single or two node setup) posted (#2) for review on master by Atin Mukherjee (amukherj)
COMMIT: http://review.gluster.org/14848 committed in master by Jeff Darcy (jdarcy) ------ commit 9a9f37440cb07ce2a1130ce39ea0d3461078f3a8 Author: Atin Mukherjee <amukherj> Date: Thu Jun 30 11:42:54 2016 +0530 glusterd: spawn daemons from init() on a single or two node setup Allow glusterd to spawn the daemons at the time of initialization when peer count is less than 2. This is required if user wants to set up a two node cluster with out server side quorum and want the bricks to come up on a node where the other node is down, however the behaviour will be overriden when server side quorum is enabled. Change-Id: I21118e996655822467eaf329f638eb9a8bf8b7d5 BUG: 1352277 Signed-off-by: Atin Mukherjee <amukherj> Reviewed-on: http://review.gluster.org/14848 Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Jeff Darcy <jdarcy>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.9.0, please open a new bug report. glusterfs-3.9.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://lists.gluster.org/pipermail/gluster-users/2016-November/029281.html [2] https://www.gluster.org/pipermail/gluster-users/