glusterfs.git -

	Commit message (Collapse)	Author	Age	Files	Lines
*	glusterd: manage upgrade to current master	Amar Tumballi	2019-02-04	1	-1/+0
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	Scenarios tested: * Upgrade the node when there are stripe / tiering and regular type of volumes are present. - All volumes are started fine (as the change was not on brick volfile) - For tier, the functionality may not even work, as changetimerecorder is not present. - 'gluster volume info' properly shows as 'NOT SUPPORTED' for stripe and tier type of volume. * Upgrade in a rolling upgrade scenario, where an old version is able to connect to higher master. - on a normal volume, if the volfile-server was new, the newer client volfiles needed to have utime xlator conditionally. - with this one change, all other changes seem to work fine. Change-Id: Ib2d3b69dafa02b2c695a735b13c1aa70aba07cb8 updates: bz#1635688 Signed-off-by: Amar Tumballi <amarts@redhat.com>
*	tests: Update tier CLI in .t files	N Balachandran	2017-10-30	1	-1/+1
\| \| \| \| \| \| \| \|	Update .t tier tests to use the new tier CLI. Change-Id: I0e7f1769071108d8266fc86378c4466bcaf96e7d BUG: 1505253 Signed-off-by: N Balachandran <nbalacha@redhat.com>
*	snapshot: Fix finding brick mount path logic	Avra Sengupta	2015-06-05	1	-0/+32
	Previously while finding brick mount paths of snap volume's bricks, we were taking brick order into consideration. This logic fails when a brick is removed or a tier is added. Hence modifying the logic to look for the first occurence of the word "brick" in the brick path. From there we iterate till we find a '/'. The string till the first '/' after we encounter the word brick is the brick mount path. Change-Id: Ic85983c4e975e701cdfd4e13f8e276ac391a3e49 BUG: 1227646 Signed-off-by: Avra Sengupta <asengupt@redhat.com> Reviewed-on: http://review.gluster.org/11060 Tested-by: Gluster Build System <jenkins@build.gluster.com> Tested-by: NetBSD Build System <jenkins@build.gluster.org> Reviewed-by: Rajesh Joseph <rjoseph@redhat.com> Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>