<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 12, 2016 at 11:40 AM, Aravinda <span dir="ltr">&lt;<a href="mailto:avishwan@redhat.com" target="_blank">avishwan@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <tt>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.</tt></div></blockquote><div><br></div><div>I&#39;d not do that if we can solve the problem in first upgrade attempt itself which looks feasible.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><br>
    <pre cols="72">regards
Aravinda</pre><div><div class="h5">
    <div>On 07/11/2016 01:56 PM, Niels de Vos
      wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      <pre>On Mon, Jul 11, 2016 at 12:56:24PM +0530, Kaushal M wrote:
</pre>
      <blockquote type="cite">
        <pre>On Sat, Jul 9, 2016 at 10:02 PM, Atin Mukherjee <a href="mailto:amukherj@redhat.com" target="_blank">&lt;amukherj@redhat.com&gt;</a> wrote:
</pre>
      </blockquote>
      <pre>...

</pre>
      <blockquote type="cite">
        <pre>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&#39;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&#39;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&#39;t regenerate anything, it is just an
indication that the cluster is now ready to use new features.)

We don&#39;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&#39;t think of any right now).

What do the other maintainers feel about this?
</pre>
      </blockquote>
      <pre>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&#39;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
</pre>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><span class=""><pre>_______________________________________________
maintainers mailing list
<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a>
<a href="http://www.gluster.org/mailman/listinfo/maintainers" target="_blank">http://www.gluster.org/mailman/listinfo/maintainers</a>
</pre>
    </span></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@gluster.org">maintainers@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/maintainers</a><br>
<br></blockquote></div><br></div></div>