[Gluster-Maintainers] Upgrade issue when new mem type is added in libglusterfs

[Kotresh Hiremath Ravishankar]

Hi,

Skippng geo-replication configuration routine during upgrade/downgrade works.
It will be configured on glusterd start after upgrade/downgrade. Here is the
patch.

http://review.gluster.org/14898


Thanks and Regards,
Kotresh H R

----- Original Message -----
> From: "Atin Mukherjee" <amukherj at redhat.com>
> To: "Aravinda" <avishwan at redhat.com>
> Cc: "Niels de Vos" <ndevos at redhat.com>, "Kaushal M" <kshlmster at gmail.com>, maintainers at gluster.org, "Kotresh Hiremath
> Ravishankar" <khiremat at redhat.com>
> Sent: Tuesday, July 12, 2016 11:51:54 AM
> Subject: Re: [Gluster-Maintainers] Upgrade issue when new mem type is added in libglusterfs
> 
> On Tue, Jul 12, 2016 at 11:40 AM, Aravinda <avishwan at redhat.com> 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 <amukherj at redhat.com>
> > <amukherj at redhat.com> 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
> > listmaintainers at gluster.orghttp://www.gluster.org/mailman/listinfo/maintainers
> >
> >
> >
> > _______________________________________________
> > maintainers mailing list
> > maintainers at gluster.org
> > http://www.gluster.org/mailman/listinfo/maintainers
> >
> >
>