Description of problem:
If gluster service is enabled on the host being put into maintenance, then glusterd and brick processes on the host should be stopped.
This is required to stop clients from accessing the data, if the host is going to be upgraded.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
should this be optional?
should it be blocked if another host in the brick-set is still healing?
I think in such cases, putting the host to maintenance mode should be blocked.
The BZs #1213291 and #1196433 would take care of not allowing other nodes to maintenance state.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Retargeting as this is required for HC mode operations
Please don't leave bugs assigned to firstname.lastname@example.org when you take it.
Moving host checks before moving to maintenance to separate bz
oVirt 3.6.2 RC1 has been released for testing, moving to ON_QA
> Itamar Heim 2015-03-29 04:55:27 EDT
>should this be optional?
>should it be blocked if another host in the brick-set is still healing?
> Shubhendu Tripathi 2015-07-14 05:04:44 EDT
>The BZs #1213291 and #1196433 would take care of not allowing other
>nodes to maintenance state.
I definitely agree that this should be optional, and definitely NOT the default behaviour, until the two above-noted BZs are implemented as well! As it now, 3.6.2 released with this change will have a very high likelyhood of breaking my oVirt cluster when moving a node to maintenance without performing very careful checks on the nodes first.
Even if the nodes are in a state that is "safe" to stop one of the glusterds, it will unnecessarily require a heal to be performed after re-activating the node.
Perhaps this isn't such a big deal in "big" clusters with dozens of nodes, but on a minimal 3-node cluster, taking one gluster node offline unnecessarily is a big risk.
There are many reasons to want to put the VDSM/hypervisor into maintenance, but NOT disrupt the gluster daemons on the same node!
As it works now (<= 3.6.1) I can safely move a node to maintenance, from the vdsm/hypervisor point-of-view without affecting the operational state of the gluster volumes.
I am now stuck on 3.6.1 until this change is reverted or augmented to be optional when placing a node into maintenance.
I recommend that this change be reverted, and this BZ should be set to depend on the two above-noted BZs.
Will rework this to make it optional, agree with the user's concerns.
Raised bug 1303539 to track it.
Tested with RHEV 220.127.116.11 and RHGS 3.1.2 RC ( glusterfs-18.104.22.168.el7rhgs )
gluster services are not stopped forcefully but an option is provided for stopping the gluster services while moving the host to maintenance