Kotresh, Can you please take care of capturing this in both 3.7.13 & 3.8.1 release notes? Content is already available in the mail thread.
Thanks, Atin On Wed, Jul 20, 2016 at 8:10 PM, Niels de Vos <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > On Tue, Jul 12, 2016 at 11:26:46AM +0530, Atin Mukherjee wrote: > > I still see the release notes for 3.8.1 & 3.7.13 not reflecting this > > change. > > > > Niels, Kaushal, > > > > Shouldn't we highlight this as early as possible to the users given > release > > note is the best possible medium to capture all the known issues and the > > work around? > > You can sent a patch to the release notes: > > https://github.com/gluster/glusterfs/blob/release-3.8/doc/release-notes/3.8.1.md > > The release notes of the previous version are normallky used/copied and > modified for the new version. A new section "known issues" before the > "Bugs addressed" would be good. > > Thanks, > Niels > > > > ~Atin > > > > > > On Sat, Jul 9, 2016 at 10:02 PM, Atin Mukherjee <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > > > > We have hit a bug 1347250 in downstream (applicable upstream too) > where it > > > was seen that glusterd didnt regenerate the volfiles when it was > interimly > > > brought up with upgrade mode by yum. Log file captured that gsyncd > > > --version failed to execute and hence glusterd init couldnt proceed > till > > > the volfile regeneration. Since the ret code is not handled here in > spec > > > file users wouldnt come to know about this and going forward this is > going > > > to cause major issues in healing and all and finally it exploits the > > > possibility of split brains at its best. > > > > > > Further analysis by Kotresh & Raghavendra Talur reveals that gsyncd > failed > > > here because of the compatibility issue where gsyncd was still not > upgraded > > > where as glusterfs-server was and this failure was mainly because of > change > > > in the mem type enum. We have seen a similar issue for RDMA as well > > > (probably a year back). So to be very generic this can happen in any > > > upgrade path from one version to another where new mem type is > introduced. > > > We have seen this from 3.7.8 to 3.7.12 and 3.8. People upgrading from > 3.6 > > > to 3.7/3.8 will also experience this issue. > > > > > > Till we work on this fix, I suggest all the release managers to > highlight > > > this in the release note of the latest releases with the following work > > > around after yum update: > > > > > > 1. grep -irns "geo-replication module not working as desired" > /var/log/glusterfs/etc-glusterfs-glusterd.vol.log | wc -l > > > > > > If the output is non-zero, then go to step 2 else follow the rest of > the steps as per the guide. > > > > > > 2.Check if glusterd instance is running or not by 'ps aux | grep > glusterd', if it is, then stop the glusterd service. > > > > > > 3. glusterd --xlator-option *.upgrade=on -N > > > > > > and then proceed ahead with rest of the steps as per the guide. > > > > > > Thoughts? > > > > > > P.S : this email is limited to maintainers till we decide on the > approach > > > to highlight this issues to the users > > > > > > > > > -- > > > Atin > > > Sent from iPhone > > > > > > _______________________________________________ > > maintainers mailing list > > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > > http://www.gluster.org/mailman/listinfo/maintainers > > -- --Atin -- Atin Sent from iPhone
_______________________________________________ maintainers mailing list [email protected] http://www.gluster.org/mailman/listinfo/maintainers
