summaryrefslogtreecommitdiffstats
path: root/xlators/cluster/dht
diff options
context:
space:
mode:
authorAtin Mukherjee <amukherj@redhat.com>2018-11-20 12:32:32 +0530
committerAmar Tumballi <amarts@redhat.com>2018-12-05 21:36:25 +0000
commitd4723bdd30f0955ca68fec8c01bc87229c6a24c0 (patch)
tree378ba7553b0f43e9de5d9a7139420e53fca48f47 /xlators/cluster/dht
parentafc3006b46bf9d6eb05e39af68bcd81041761a9c (diff)
glusterd: glusterd to regenerate volfiles when GD_OP_VERSION_MAX changes
While glusterd has an infra to allow post install of spec to bring it up in the interim upgrade mode to allow all the volfiles to be regenerated with the latest executable, in container world the same methodology is not followed as container image always point to the specific gluster rpm and gluster rpm doesn't go through an upgrade process. This fix does the following: 1. If glusterd.upgrade file doesn't exist, regenerate the volfiles 2. If maximum-operating-version read from glusterd.upgrade doesn't match with GD_OP_VERSION_MAX, glusterd detects it to be a version where new options are introduced and regenerate the volfiles. Tests done: 1. Bring up glusterd, check if glusterd.upgrade file has been created with GD_OP_VERSION_MAX value. 2. Post 1, restart glusterd and check glusterd hasn't regenerated the volfiles as there's is no change in the GD_OP_VERSION_MAX vs the op_version read from the file. 3. Bump up the GD_OP_VERSION_MAX in the code by 1 and post compilation restart glusterd where the volfiles should be again regenerated. Note: The old way of having volfiles regenerated during an rpm upgrade is kept as it is for now but eventually this can be sunset later. Change-Id: I75b49a1601c71e99f6a6bc360dd12dd03a96414b Fixes: bz#1651463 Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
Diffstat (limited to 'xlators/cluster/dht')
0 files changed, 0 insertions, 0 deletions