Gluster users - May 2017 - [Gluster-Maintainers] [Gluster-devel] Backport for "Add back socket for polling of events immediately..."

----- Original Message -----
> From: "Zhang Huan" <zhanghuan at open-fs.com>
> To: "Raghavendra G" <raghavendra at gluster.com>
> Cc: "GlusterFS Maintainers" <maintainers at gluster.org>,
"Gluster Devel" <gluster-devel at gluster.org>, "Kaushal
Madappa"
> <kmadappa at redhat.com>
> Sent: Tuesday, May 30, 2017 3:33:09 PM
> Subject: Re: [Gluster-Maintainers] [Gluster-devel] Backport for "Add
back socket for polling of events
> immediately..."
> 
> 
> 
> 
> On 29 May 2017, at 11:16, Raghavendra G < raghavendra at gluster.com
> wrote:
> 
> Replying to all queries here:
> 
> * Is it a bug or performance enhancement?
> Its a performance enhancement. No functionality is broken if this patch is
> not taken in.
> 
> * Are there performance numbers to validate the claim?
> https://bugzilla.redhat.com/show_bug.cgi?id=1358606#c9
> 
> * Are there any existing users who need this enhancement?
> https://bugzilla.redhat.com/show_bug.cgi?id=1358606#c27
> 
> Though not sure what branch Zhang Huan is on. @Zhang your inputs are needed
> here.
> 
> We are currently on 3.8. Thus the performance number is based on 3.8.
> If you need more details, please let me know.
Thanks Zhang. The question was more on the lines whether you need backport of
the fix to 3.8. Can you upgrade to recent releases (say 3.11.x or 3.10.x)?
> 
> 
> 
> 
> 
> * Do I think this patch _should_ go into any of the released branches?
> Personally, I don't feel strongly either way. I am fine with this patch
not
> making into any of released branches. But, I do think there are users who
> are affected with this (Especially EC/Disperse configurations). If they
want
> to stick to the released branches, pulling into released branches will help
> them. @Pranith/Xavi, what are your opinions on this?
> 
> regards,
> Raghavendra
> 
> On Sun, May 28, 2017 at 6:58 PM, Shyam < srangana at redhat.com >
wrote:
> 
> 
> On 05/28/2017 09:24 AM, Atin Mukherjee wrote:
> 
> 
> 
> 
> On Sun, May 28, 2017 at 1:48 PM, Niels de Vos < ndevos at redhat.com
> <mailto: ndevos at redhat.com >> wrote:
> 
> On Fri, May 26, 2017 at 12:25:42PM -0400, Shyam wrote:
> > Or this one: https://review.gluster.org/15036 <
> > https://review.gluster.org/15036 >
> > 
> > This is backported to 3.8/10 and 3.11 and considering the size and
impact
> > of
> > the change, I wanted to be sure that we are going to accept this
across all
> > 3 releases?
> > 
> > @Du, would like your thoughts on this.
> > 
> > @niels, @kaushal, @talur, as release owners, could you weigh in as
well
> > please.
> > 
> > I am thinking that we get this into 3.11.1 if there is agreement, and
not
> > in
> > 3.11.0 as we are finalizing the release in 3 days, and this change
looks
> > big, to get in at this time.
> 
> 
> Given 3.11 is going to be a new release, I'd recommend to get this fix
> in (if we have time). https://review.gluster.org/#/c/17402/ is dependent
> on this one.
> 
> It is not a fix Atin, it is a more fundamental change to request
processing,
> with 2 days to the release, you want me to merge this?
> 
> Is there a *bug* that will surface without this change or is it a
performance
> enhancement?
> 
> 
> 
> 
> > 
> > Further the change is actually an enhancement, and provides
performance
> > benefits, so it is valid as a change itself, but I feel it is too late
to
> > add to the current 3.11 release.
> 
> Indeed, and mostly we do not merge enhancements that are non-trivial to
> stable branches. Each change that we backport introduces the chance on
> regressions for users with their unknown (and possibly awkward)
> workloads.
> 
> The patch itself looks ok, but it is difficult to predict how the change
> affects current deployments. I prefer to be conservative and not have
> this merged in 3.8, at least for now. Are there any statistics in how
> performance is affected with this change? Having features like this only
> in newer versions might also convince users to upgrade sooner, 3.8 will
> only be supported until 3.12 (or 4.0) gets released, which is approx. 3
> months from now according to our schedule.
> 
> Niels
> 
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org <mailto: maintainers at gluster.org >
> http://lists.gluster.org/mailman/listinfo/maintainers
> < http://lists.gluster.org/mailman/listinfo/maintainers >
> 
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
> 
> 
> 
> --
> Raghavendra G
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
> 
> 
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>

> On 30 May 2017, at 19:58, Raghavendra Gowdappa <rgowdapp at
redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "Zhang Huan" <zhanghuan at open-fs.com
<mailto:zhanghuan at open-fs.com>>
>> To: "Raghavendra G" <raghavendra at gluster.com
<mailto:raghavendra at gluster.com>>
>> Cc: "GlusterFS Maintainers" <maintainers at gluster.org
<mailto:maintainers at gluster.org>>, "Gluster Devel"
<gluster-devel at gluster.org <mailto:gluster-devel at
gluster.org>>, "Kaushal Madappa"
>> <kmadappa at redhat.com <mailto:kmadappa at redhat.com>>
>> Sent: Tuesday, May 30, 2017 3:33:09 PM
>> Subject: Re: [Gluster-Maintainers] [Gluster-devel] Backport for
"Add back socket for polling of events
>> immediately..."
>> 
>> 
>> 
>> 
>> On 29 May 2017, at 11:16, Raghavendra G < raghavendra at gluster.com
> wrote:
>> 
>> Replying to all queries here:
>> 
>> * Is it a bug or performance enhancement?
>> Its a performance enhancement. No functionality is broken if this patch
is
>> not taken in.
>> 
>> * Are there performance numbers to validate the claim?
>> https://bugzilla.redhat.com/show_bug.cgi?id=1358606#c9
>> 
>> * Are there any existing users who need this enhancement?
>> https://bugzilla.redhat.com/show_bug.cgi?id=1358606#c27
>> 
>> Though not sure what branch Zhang Huan is on. @Zhang your inputs are
needed
>> here.
>> 
>> We are currently on 3.8. Thus the performance number is based on 3.8.
>> If you need more details, please let me know.
> 
> Thanks Zhang. The question was more on the lines whether you need backport
of the fix to 3.8.
Actually, we really need this backported to 3.8. I have seen the backport of it
to 3.8.
https://review.gluster.org/#/c/15046/
<https://review.gluster.org/#/c/15046/>
Once it gets merged, we will rebase to it and test it as a whole.
> Can you upgrade to recent releases (say 3.11.x or 3.10.x)?
Sorry, I am afraid not. Gusterfs is one of the key components in our product. An
upgrade alone would break the whole thing.

> 
>> 
>> 
>> 
>> 
>> 
>> * Do I think this patch _should_ go into any of the released branches?
>> Personally, I don't feel strongly either way. I am fine with this
patch not
>> making into any of released branches. But, I do think there are users
who
>> are affected with this (Especially EC/Disperse configurations). If they
want
>> to stick to the released branches, pulling into released branches will
help
>> them. @Pranith/Xavi, what are your opinions on this?
>> 
>> regards,
>> Raghavendra
>> 
>> On Sun, May 28, 2017 at 6:58 PM, Shyam < srangana at redhat.com >
wrote:
>> 
>> 
>> On 05/28/2017 09:24 AM, Atin Mukherjee wrote:
>> 
>> 
>> 
>> 
>> On Sun, May 28, 2017 at 1:48 PM, Niels de Vos < ndevos at redhat.com
>> <mailto: ndevos at redhat.com >> wrote:
>> 
>> On Fri, May 26, 2017 at 12:25:42PM -0400, Shyam wrote:
>>> Or this one: https://review.gluster.org/15036 <
>>> https://review.gluster.org/15036 >
>>> 
>>> This is backported to 3.8/10 and 3.11 and considering the size and
impact
>>> of
>>> the change, I wanted to be sure that we are going to accept this
across all
>>> 3 releases?
>>> 
>>> @Du, would like your thoughts on this.
>>> 
>>> @niels, @kaushal, @talur, as release owners, could you weigh in as
well
>>> please.
>>> 
>>> I am thinking that we get this into 3.11.1 if there is agreement,
and not
>>> in
>>> 3.11.0 as we are finalizing the release in 3 days, and this change
looks
>>> big, to get in at this time.
>> 
>> 
>> Given 3.11 is going to be a new release, I'd recommend to get this
fix
>> in (if we have time). https://review.gluster.org/#/c/17402/ is
dependent
>> on this one.
>> 
>> It is not a fix Atin, it is a more fundamental change to request
processing,
>> with 2 days to the release, you want me to merge this?
>> 
>> Is there a *bug* that will surface without this change or is it a
performance
>> enhancement?
>> 
>> 
>> 
>> 
>>> 
>>> Further the change is actually an enhancement, and provides
performance
>>> benefits, so it is valid as a change itself, but I feel it is too
late to
>>> add to the current 3.11 release.
>> 
>> Indeed, and mostly we do not merge enhancements that are non-trivial to
>> stable branches. Each change that we backport introduces the chance on
>> regressions for users with their unknown (and possibly awkward)
>> workloads.
>> 
>> The patch itself looks ok, but it is difficult to predict how the
change
>> affects current deployments. I prefer to be conservative and not have
>> this merged in 3.8, at least for now. Are there any statistics in how
>> performance is affected with this change? Having features like this
only
>> in newer versions might also convince users to upgrade sooner, 3.8 will
>> only be supported until 3.12 (or 4.0) gets released, which is approx. 3
>> months from now according to our schedule.
>> 
>> Niels
>> 
>> _______________________________________________
>> maintainers mailing list
>> maintainers at gluster.org <mailto: maintainers at gluster.org >
>> http://lists.gluster.org/mailman/listinfo/maintainers
>> < http://lists.gluster.org/mailman/listinfo/maintainers >
>> 
>> 
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>> 
>> 
>> 
>> --
>> Raghavendra G
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>> 
>> 
>> _______________________________________________
>> maintainers mailing list
>> maintainers at gluster.org <mailto:maintainers at gluster.org>
>> http://lists.gluster.org/mailman/listinfo/maintainers
<http://lists.gluster.org/mailman/listinfo/maintainers>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20170531/ba931e11/attachment.html>

On 05/30/2017 08:44 PM, Zhang Huan wrote:
>>> * Are there any existing users who need this enhancement?
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1358606#c27
>>>
>>> Though not sure what branch Zhang Huan is on. @Zhang your inputs
are
>>> needed
>>> here.
>>>
>>> We are currently on 3.8. Thus the performance number is based on
3.8.
>>> If you need more details, please let me know.
>>
>> Thanks Zhang. The question was more on the lines whether you need
>> backport of the fix to 3.8.
>
> Actually, we really need this backported to 3.8. I have seen the
> backport of it to 3.8.
> https://review.gluster.org/#/c/15046/
> Once it gets merged, we will rebase to it and test it as a whole.
@Zang and @list, as this is a performance improvement feature and we do 
not backport features into releases (as a rule) that are already out in 
the field, hence we will not be backporting this to 3.8.

Further, 3.8 will EOL (end of life) from a maintenance standpoint when 
3.12 is released (scheduled around Aug 30th).

We would be merging this into 3.11.1 to provide early access for tests 
and such (Release date of June 20th), and this feature would be made 
generally available with 3.12.

We regret any inconvenience.
>
>> Can you upgrade to recent releases (say 3.11.x or 3.10.x)?
>
> Sorry, I am afraid not. Gusterfs is one of the key components in our
> product. An upgrade alone would break the whole thing.