<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 31, 2017 at 2:36 AM, Xavier Hernandez <span dir="ltr"><<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Atin,<span class=""><br>
<br>
On 31/01/17 05:45, Atin Mukherjee wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Mon, Jan 30, 2017 at 9:02 PM, Xavier Hernandez <<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a><br></span><span class="">
<mailto:<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>><wbr>> wrote:<br>
<br>
Hi Atin,<br>
<br>
On 30/01/17 15:25, Atin Mukherjee wrote:<br>
<br>
<br>
<br>
On Mon, Jan 30, 2017 at 7:30 PM, Xavier Hernandez<br>
<<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a> <mailto:<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>><br></span>
<mailto:<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a> <mailto:<a href="mailto:xhernandez@datalab.es" target="_blank">xhernandez@datalab.es</a>><wbr>>><div><div class="h5"><br>
wrote:<br>
<br>
Hi,<br>
<br>
I'm wondering how a new option needs to be created to be<br>
available<br>
to different versions of gluster.<br>
<br>
When a new option is created for 3.7 for example, it needs<br>
to have a<br>
GD_OP_VERSION referencing the next 3.7 release. This ensures<br>
that<br>
there won't be any problem with previous versions.<br>
<br>
However what happens with 3.8 ?<br>
<br>
3.8.0 is greater than any 3.7.x, however the new option won't be<br>
available until the next 3.8 release. How this needs to be<br>
handled ?<br>
<br>
<br>
I'd discourage to backport any new volume options from mainline<br>
to the<br>
stable releases branches like 3.7 & 3.8. This creates a lot of<br>
backward<br>
compatibility issues w.r.t clients. Any new option is actually<br>
an RFE<br>
and supposed to be slated for only upcoming releases.<br>
<br>
<br>
Even if it's needed to solve an issue in all versions ?<br>
<br>
For example, a hardcoded timeout is seen to be insufficient in some<br>
configurations, so it needs to be increased, but increasing it will<br>
be too much for many of the environments where the current timeout<br>
has worked fine. It could even be not enough for other environments<br>
still not tried, needed a future increase.<br>
<br>
With a new option, this can be solved case by case and only when needed.<br>
<br>
How can this be solved ?<br>
<br>
<br>
Hi Xavi,<br>
<br>
Let me try to explain this a bit in detail. A new option with an<br>
op-version say 30721 (considering 3.7.21 is the next update of 3.7 which<br>
is the oldest active branch) is introduced in mainline and then the same<br>
is backported to 3.7 (slated for 3.7.21) & 3.8 branch (slated for<br>
3.8.9). Now say if an user forms a cluster of three nodes with gluster<br>
versions as 3.7.21, 3.8.9 & 3.8.8 respectively and tries to set this<br>
option, volume set would always fail as in 3.8.8 this option is not<br>
defined. Also any client running with 3.8 version would see a<br>
compatibility issue here. Also the op-version number of the new option<br>
has to be same across different release branches.<br>
</div></div></blockquote>
<br>
Thanks for the explanation. This confirms what I already thought. So the question is: now that 3.10 has already been branched, does it mean that any new option won't be available for LTS users until 3.12 is released ? I think this is not acceptable, specially for changes intended to fix an issue, not introducing new features.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
With the current form of op-version management, I don't think this can<br>
be solved, the only way is to ask users to upgrade to the latest.<br>
</blockquote>
<br></span>
As I said, someone using 3.10 LTS won't be able to upgrade until 3.12 is released. What would we say to them when we add a new option to 3.11 ?<br>
<br>
Maybe we should add a new kind of option that causes no failure if not recognized. They are simply ignored. Many options do not cause any visible functional change, so they could be defined even if some nodes of the cluster don't recognize them (for example performance improvement options or some timeout values).<br></blockquote><div><br></div><div><br></div><div>I like this idea. This will give us some flexibility for defining options.</div><div><br></div><div>-Vijay </div></div></div></div>