On Tue, Jul 12, 2016 at 11:40 AM, Aravinda <[email protected]> wrote:
> How about running the same upgrade steps again after %post > geo-replication. Upgrade steps will run twice(fails in first step) but it > solves these issues. > I'd not do that if we can solve the problem in first upgrade attempt itself which looks feasible. > > regards > Aravinda > > On 07/11/2016 01:56 PM, Niels de Vos wrote: > > On Mon, Jul 11, 2016 at 12:56:24PM +0530, Kaushal M wrote: > > On Sat, Jul 9, 2016 at 10:02 PM, Atin Mukherjee <[email protected]> > <[email protected]> wrote: > > ... > > > GlusterD depends on the cluster op-version when generating volfiles, > to insert new features/xlators into the volfile graph. > This was done to make sure that the homogeneity of the volfiles is > preserved across the cluster. > This behaviour makes running GlusterD in upgrade mode after a package > upgrade, essentially a noop. > The cluster op-version doesn't change automatically when packages are > upgraded, > so the regenerated volfiles in the post-upgrade section are basically > the same as before. > (If something is getting added into volfiles after this, it is > incorrect, and is something I'm yet to check). > > The correct time to regenerate the volfiles is after all members of > the cluster have been upgraded and the cluster op-version has been > bumped. > (Bumping op-version doesn't regenerate anything, it is just an > indication that the cluster is now ready to use new features.) > > We don't have a direct way to get volfiles regenerated on all members > with a single command yet. We can implement such a command with > relative ease. > For now, volfiles can regenerated by making use of the `volume set` > command, by setting a `user.upgrade` option on a volume. > Options in the `user.` namespace are passed on to hook scripts and not > added into any volfiles, but setting such an option on a volume causes > GlusterD to regenerate volfiles for the volume. > > My suggestion would be to stop using glusterd in upgrade mode during > post-upgrade to regenerate volfiles, and document the above way to get > volfiles regenerated across the cluster correctly. > We could do away with upgrade mode itself, but it could be useful for > other things (Though I can't think of any right now). > > What do the other maintainers feel about this? > > Would it make sense to have the volfiles regenerated when changing the > op-version? For environments where multiple volumes are used, I do not > like the need to regenerate them manually for all of them. > > On the other hand, a regenerate+reload/restart results in a short > interruption. This may not be suitable for all volumes at the same time. > A per volume option might be preferred by some users. Getting the > feedback from users would be good before deciding on an approach. > > Running GlusterD in upgrade mode while updating the installed binaries > is something that easily gets forgotten. I'm not even sure if this is > done in all packages, and I guess it is skipped a lot when people have > installations from source. We should probably put the exact steps in our > release-notes to remind everyone. > > Thanks, > Niels > > > > _______________________________________________ > maintainers mailing > [email protected]http://www.gluster.org/mailman/listinfo/maintainers > > > > _______________________________________________ > maintainers mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/maintainers > >
_______________________________________________ maintainers mailing list [email protected] http://www.gluster.org/mailman/listinfo/maintainers
