<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 14, 2018 at 9:48 PM, Atin Mukherjee <span dir="ltr"><<a href="mailto:amukherj@redhat.com" target="_blank">amukherj@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Mar 15, 2018 at 9:45 AM, Vijay Bellur <span dir="ltr"><<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_2340771356870251025h5">On Wed, Mar 14, 2018 at 5:40 PM, Shyam Ranganathan <span dir="ltr"><<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 03/14/2018 07:04 PM, Joe Julian wrote:<br>
><br>
><br>
> On 03/14/2018 02:25 PM, Vijay Bellur wrote:<br>
>><br>
>><br>
>> On Tue, Mar 13, 2018 at 4:25 AM, Kaleb S. KEITHLEY<br>
</span><div><div class="m_2340771356870251025m_-2937670083363663567h5">>> <<a href="mailto:kkeithle@redhat.com" target="_blank">kkeithle@redhat.com</a> <mailto:<a href="mailto:kkeithle@redhat.com" target="_blank">kkeithle@redhat.com</a>>> wrote:<br>
>><br>
>> On 03/12/2018 02:32 PM, Shyam Ranganathan wrote:<br>
>> > On 03/12/2018 10:34 AM, Atin Mukherjee wrote:<br>
>> >> *<br>
>> >><br>
>> >> After 4.1, we want to move to either continuous<br>
>> numbering (like<br>
>> >> Fedora), or time based (like ubuntu etc) release<br>
>> numbers. Which<br>
>> >> is the model we pick is not yet finalized. Happy to<br>
>> hear opinions.<br>
>> >><br>
>> >><br>
>> >> Not sure how the time based release numbers would make more<br>
>> sense than<br>
>> >> the one which Fedora follows. But before I comment further on<br>
>> this I<br>
>> >> need to first get a clarity on how the op-versions will be<br>
>> managed. I'm<br>
>> >> assuming once we're at GlusterFS 4.1, post that the releases<br>
>> will be<br>
>> >> numbered as GlusterFS5, GlusterFS6 ... So from that<br>
>> perspective, are we<br>
>> >> going to stick to our current numbering scheme of op-version<br>
>> where for<br>
>> >> GlusterFS5 the op-version will be 50000?<br>
>> ><br>
>> > Say, yes.<br>
>> ><br>
>> > The question is why tie the op-version to the release number? That<br>
>> > mental model needs to break IMO.<br>
>> ><br>
>> > With current options like,<br>
>> > <a href="https://docs.gluster.org/en/latest/Upgrade-Guide/op_version/" rel="noreferrer" target="_blank">https://docs.gluster.org/en/la<wbr>test/Upgrade-Guide/op_version/</a><br>
>> <<a href="https://docs.gluster.org/en/latest/Upgrade-Guide/op_version/" rel="noreferrer" target="_blank">https://docs.gluster.org/en/<wbr>latest/Upgrade-Guide/op_versio<wbr>n/</a>> it is<br>
>> > easier to determine the op-version of the cluster and what it<br>
>> should be,<br>
>> > and hence this need not be tied to the gluster release version.<br>
>> ><br>
>> > Thoughts?<br>
>><br>
>> I'm okay with that, but——<br>
>><br>
>> Just to play the Devil's Advocate, having an op-version that bears<br>
>> some<br>
>> resemblance to the _version_ number may make it easy/easier to<br>
>> determine<br>
>> what the op-version ought to be.<br>
>><br>
>> We aren't going to run out of numbers, so there's no reason to be<br>
>> "efficient" here. Let's try to make it easy. (Easy to not make a<br>
>> mistake.)<br>
>><br>
>> My 2¢<br>
>><br>
>><br>
>> +1 to the overall release cadence change proposal and what Kaleb<br>
>> mentions here. <br>
>><br>
>> Tying op-versions to release numbers seems like an easier approach<br>
>> than others & one to which we are accustomed to. What are the benefits<br>
>> of breaking this model?<br>
>><br>
> There is a bit of confusion among the user base when a release happens<br>
> but the op-version doesn't have a commensurate bump. People ask why they<br>
> can't set the op-version to match the gluster release version they have<br>
> installed. If it was completely disconnected from the release version,<br>
> that might be a great enough mental disconnect that the expectation<br>
> could go away which would actually cause less confusion.<br>
<br>
</div></div>Above is the reason I state it as well (the breaking of the mental model<br>
around this), why tie it together when it is not totally related. I also<br>
agree that, the notion is present that it is tied together and hence<br>
related, but it may serve us better to break it.<br><span class="m_2340771356870251025m_-2937670083363663567HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div><br></div></div></div><div>I see your perspective. Another related reason for not introducing an op-version bump in a new release would be that there are no incompatible features introduced (in the new release). Hence it makes sense to preserve the older op-version.</div><div><br></div><div>To make everyone's lives simpler, would it be useful to introduce a command that provides the max op-version to release number mapping? The output of the command could look like:</div><div><br></div><div>op-version X: 3.7.0 to 3.7.11</div><div>op-version Y: 3.7.12 to x.y.z</div></div></div></div></blockquote><div><br></div></div></div><div>We already have introduced an option called cluster.max-op-version where one can run a command like "gluster v get all cluster.max-op-version" to determine what highest op-version the cluster can be bumped up to. IMO, this helps users not to look at the document for at given x.y.z release the op-version has to be bumped up to XXXXX . Isn't that sufficient for this requirement?<br></div></div></div></div></blockquote><div><br></div><div><br></div><div>I think it is a more elegant solution than what I described. Do we have a single interface to determine the current & max op-versions of all members in the trusted storage pool? If not, it might be an useful enhancement to add at some point in time.</div><div><br></div><div>If we don't hear much complaints about op-version mismatches from users, I think the CLI you described could be sufficient for understanding the cluster operating version.</div><div><br></div><div><br></div><div>Thanks,</div><div>Vijay</div></div></div></div>