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

[Niels de Vos]

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> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160711/c87aa7e3/attachment-0001.sig>