You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-dev@hadoop.apache.org by Colin McCabe <cm...@alumni.cmu.edu> on 2013/04/02 01:32:07 UTC
VOTE: HDFS-347 merge
Hi all,
I think it's time to merge the HDFS-347 branch back to trunk. It's been under
review and testing for several months, and provides both a performance
advantage, and the ability to use short-circuit local reads without
compromising system security.
Previously, we tried to merge this and the objection was brought up that we
should keep the old, insecure short-circuit local reads around so that
platforms for which secure SCR had not yet been implemented could use it
(e.g. Windows). This has been addressed-- see HDFS-4538 for details.
Suresh has also volunteered to maintain the insecure SCR code until secure
SCR can be implemented for Windows.
Please cast your vote by EOD Monday 4/8.
best,
Colin
Re: VOTE: HDFS-347 merge
Posted by Suresh Srinivas <su...@hortonworks.com>.
+1 for the merge. Some of the minor changes or discussions happening in
some of the related tasks can be addressed post merge to trunk. The pending
discussions/issues should be fixed before this feature gets merged into
branch-2.
On Tue, Apr 2, 2013 at 10:38 AM, Colin McCabe <cm...@alumni.cmu.edu>wrote:
> On Mon, Apr 1, 2013 at 6:58 PM, Colin McCabe <cm...@alumni.cmu.edu>
> wrote:
>
> > On Mon, Apr 1, 2013 at 5:04 PM, Suresh Srinivas <suresh@hortonworks.com
> >wrote:
> >
> >> Colin,
> >>
> >> For the record, the last email in the previous thread in ended with the
> >> following comment from Nicholas:
> >> > It is great to hear that you agree to keep HDFS-2246. Please as well
> >> address my comments posted on HDFS-347 and let me know once you have
> >> posted
> >> a new patch on HDFS-347.
> >>
> >>
> > Hi Nicholas,
> >
> > Can you please open a JIRA listing what you think should be fixed or
> > changed, and why?
> >
> > Also please specify whether it is important to fix this before the merge,
> > and if so, why. If this is a minor style change, or renaming function X
> to
> > Y, then I think we can easily do it after the merge.
> >
> > thanks,
> > Colin
> >
> >
> Hi Nicholas,
>
> I opened https://issues.apache.org/jira/browse/HDFS-4661 with some of the
> style fixes that you suggested in HDFS-347. If there is anything else you
> would like to see addressed before the merge, please add it to this JIRA.
>
> thanks,
> Colin
>
>
>
> >
> >
> >> I did not see any response (unless I missed it). Can you please address
> >> it?
> >>
> >> Regards,
> >> Suresh
> >>
> >>
> >> On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cm...@alumni.cmu.edu>
> >> wrote:
> >>
> >> > Hi all,
> >> >
> >> > I think it's time to merge the HDFS-347 branch back to trunk. It's
> been
> >> > under
> >> > review and testing for several months, and provides both a performance
> >> > advantage, and the ability to use short-circuit local reads without
> >> > compromising system security.
> >> >
> >> > Previously, we tried to merge this and the objection was brought up
> >> that we
> >> > should keep the old, insecure short-circuit local reads around so that
> >> > platforms for which secure SCR had not yet been implemented could use
> it
> >> > (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
> >> > Suresh has also volunteered to maintain the insecure SCR code until
> >> secure
> >> > SCR can be implemented for Windows.
> >> >
> >> > Please cast your vote by EOD Monday 4/8.
> >> >
> >> > best,
> >> > Colin
> >> >
> >>
> >>
> >>
> >> --
> >> http://hortonworks.com/download/
> >>
> >
> >
>
--
http://hortonworks.com/download/
Re: VOTE: HDFS-347 merge
Posted by Tsz Wo Sze <sz...@yahoo.com>.
Hi Colin,
Thanks for filing HDFS-4661. Will watch it.
For the latest patch in HDFS-347, it seems that there are still bugs in the patch. I have posted some comments on HDFS-347.
Thanks again.
Nicholas
________________________________
From: Colin McCabe <cm...@alumni.cmu.edu>
To: hdfs-dev@hadoop.apache.org
Sent: Wednesday, April 3, 2013 1:38 AM
Subject: Re: VOTE: HDFS-347 merge
On Mon, Apr 1, 2013 at 6:58 PM, Colin McCabe <cm...@alumni.cmu.edu> wrote:
> On Mon, Apr 1, 2013 at 5:04 PM, Suresh Srinivas <su...@hortonworks.com>wrote:
>
>> Colin,
>>
>> For the record, the last email in the previous thread in ended with the
>> following comment from Nicholas:
>> > It is great to hear that you agree to keep HDFS-2246. Please as well
>> address my comments posted on HDFS-347 and let me know once you have
>> posted
>> a new patch on HDFS-347.
>>
>>
> Hi Nicholas,
>
> Can you please open a JIRA listing what you think should be fixed or
> changed, and why?
>
> Also please specify whether it is important to fix this before the merge,
> and if so, why. If this is a minor style change, or renaming function X to
> Y, then I think we can easily do it after the merge.
>
> thanks,
> Colin
>
>
Hi Nicholas,
I opened https://issues.apache.org/jira/browse/HDFS-4661 with some of the
style fixes that you suggested in HDFS-347. If there is anything else you
would like to see addressed before the merge, please add it to this JIRA.
thanks,
Colin
>
>
>> I did not see any response (unless I missed it). Can you please address
>> it?
>>
>> Regards,
>> Suresh
>>
>>
>> On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cm...@alumni.cmu.edu>
>> wrote:
>>
>> > Hi all,
>> >
>> > I think it's time to merge the HDFS-347 branch back to trunk. It's been
>> > under
>> > review and testing for several months, and provides both a performance
>> > advantage, and the ability to use short-circuit local reads without
>> > compromising system security.
>> >
>> > Previously, we tried to merge this and the objection was brought up
>> that we
>> > should keep the old, insecure short-circuit local reads around so that
>> > platforms for which secure SCR had not yet been implemented could use it
>> > (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
>> > Suresh has also volunteered to maintain the insecure SCR code until
>> secure
>> > SCR can be implemented for Windows.
>> >
>> > Please cast your vote by EOD Monday 4/8.
>> >
>> > best,
>> > Colin
>> >
>>
>>
>>
>> --
>> http://hortonworks.com/download/
>>
>
>
Re: VOTE: HDFS-347 merge
Posted by Colin McCabe <cm...@alumni.cmu.edu>.
On Mon, Apr 1, 2013 at 6:58 PM, Colin McCabe <cm...@alumni.cmu.edu> wrote:
> On Mon, Apr 1, 2013 at 5:04 PM, Suresh Srinivas <su...@hortonworks.com>wrote:
>
>> Colin,
>>
>> For the record, the last email in the previous thread in ended with the
>> following comment from Nicholas:
>> > It is great to hear that you agree to keep HDFS-2246. Please as well
>> address my comments posted on HDFS-347 and let me know once you have
>> posted
>> a new patch on HDFS-347.
>>
>>
> Hi Nicholas,
>
> Can you please open a JIRA listing what you think should be fixed or
> changed, and why?
>
> Also please specify whether it is important to fix this before the merge,
> and if so, why. If this is a minor style change, or renaming function X to
> Y, then I think we can easily do it after the merge.
>
> thanks,
> Colin
>
>
Hi Nicholas,
I opened https://issues.apache.org/jira/browse/HDFS-4661 with some of the
style fixes that you suggested in HDFS-347. If there is anything else you
would like to see addressed before the merge, please add it to this JIRA.
thanks,
Colin
>
>
>> I did not see any response (unless I missed it). Can you please address
>> it?
>>
>> Regards,
>> Suresh
>>
>>
>> On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cm...@alumni.cmu.edu>
>> wrote:
>>
>> > Hi all,
>> >
>> > I think it's time to merge the HDFS-347 branch back to trunk. It's been
>> > under
>> > review and testing for several months, and provides both a performance
>> > advantage, and the ability to use short-circuit local reads without
>> > compromising system security.
>> >
>> > Previously, we tried to merge this and the objection was brought up
>> that we
>> > should keep the old, insecure short-circuit local reads around so that
>> > platforms for which secure SCR had not yet been implemented could use it
>> > (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
>> > Suresh has also volunteered to maintain the insecure SCR code until
>> secure
>> > SCR can be implemented for Windows.
>> >
>> > Please cast your vote by EOD Monday 4/8.
>> >
>> > best,
>> > Colin
>> >
>>
>>
>>
>> --
>> http://hortonworks.com/download/
>>
>
>
Re: VOTE: HDFS-347 merge
Posted by Colin McCabe <cm...@alumni.cmu.edu>.
On Mon, Apr 1, 2013 at 5:04 PM, Suresh Srinivas <su...@hortonworks.com>wrote:
> Colin,
>
> For the record, the last email in the previous thread in ended with the
> following comment from Nicholas:
> > It is great to hear that you agree to keep HDFS-2246. Please as well
> address my comments posted on HDFS-347 and let me know once you have posted
> a new patch on HDFS-347.
>
>
Hi Nicholas,
Can you please open a JIRA listing what you think should be fixed or
changed, and why?
Also please specify whether it is important to fix this before the merge,
and if so, why. If this is a minor style change, or renaming function X to
Y, then I think we can easily do it after the merge.
thanks,
Colin
> I did not see any response (unless I missed it). Can you please address it?
>
> Regards,
> Suresh
>
>
> On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cm...@alumni.cmu.edu>
> wrote:
>
> > Hi all,
> >
> > I think it's time to merge the HDFS-347 branch back to trunk. It's been
> > under
> > review and testing for several months, and provides both a performance
> > advantage, and the ability to use short-circuit local reads without
> > compromising system security.
> >
> > Previously, we tried to merge this and the objection was brought up that
> we
> > should keep the old, insecure short-circuit local reads around so that
> > platforms for which secure SCR had not yet been implemented could use it
> > (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
> > Suresh has also volunteered to maintain the insecure SCR code until
> secure
> > SCR can be implemented for Windows.
> >
> > Please cast your vote by EOD Monday 4/8.
> >
> > best,
> > Colin
> >
>
>
>
> --
> http://hortonworks.com/download/
>
Re: VOTE: HDFS-347 merge
Posted by Suresh Srinivas <su...@hortonworks.com>.
Colin,
For the record, the last email in the previous thread in ended with the
following comment from Nicholas:
> It is great to hear that you agree to keep HDFS-2246. Please as well
address my comments posted on HDFS-347 and let me know once you have posted
a new patch on HDFS-347.
I did not see any response (unless I missed it). Can you please address it?
Regards,
Suresh
On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cm...@alumni.cmu.edu> wrote:
> Hi all,
>
> I think it's time to merge the HDFS-347 branch back to trunk. It's been
> under
> review and testing for several months, and provides both a performance
> advantage, and the ability to use short-circuit local reads without
> compromising system security.
>
> Previously, we tried to merge this and the objection was brought up that we
> should keep the old, insecure short-circuit local reads around so that
> platforms for which secure SCR had not yet been implemented could use it
> (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
> Suresh has also volunteered to maintain the insecure SCR code until secure
> SCR can be implemented for Windows.
>
> Please cast your vote by EOD Monday 4/8.
>
> best,
> Colin
>
--
http://hortonworks.com/download/
Re: VOTE: HDFS-347 merge
Posted by Colin McCabe <cm...@alumni.cmu.edu>.
Let's extend this vote by another 2 days just in case Nicholas doesn't find
time in his schedule today to comment.
He needs to withdraw his -1 before we can proceed.
Colin
On Mon, Apr 8, 2013 at 1:19 PM, Todd Lipcon <to...@cloudera.com> wrote:
> +1 for the branch merge. I've reviewed all of the code in the branch, and
> we have people now running this code in production scenarios. It is as
> functional as the old version and way easier to set up/configure.
>
> -Todd
>
> On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cm...@alumni.cmu.edu>
> wrote:
>
> > Hi all,
> >
> > I think it's time to merge the HDFS-347 branch back to trunk. It's been
> > under
> > review and testing for several months, and provides both a performance
> > advantage, and the ability to use short-circuit local reads without
> > compromising system security.
> >
> > Previously, we tried to merge this and the objection was brought up that
> we
> > should keep the old, insecure short-circuit local reads around so that
> > platforms for which secure SCR had not yet been implemented could use it
> > (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
> > Suresh has also volunteered to maintain the insecure SCR code until
> secure
> > SCR can be implemented for Windows.
> >
> > Please cast your vote by EOD Monday 4/8.
> >
> > best,
> > Colin
> >
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>
Re: VOTE: HDFS-347 merge
Posted by Azuryy Yu <az...@gmail.com>.
Thanks Colin.
--Send from my Sony mobile.
On Apr 13, 2013 4:06 AM, "Colin McCabe" <cm...@alumni.cmu.edu> wrote:
> Hi Azuryy,
>
> The branch adds new APT documentation which describes the new configuration
> that is needed.
> It's
> in
> ./hadoop-hdfs-project/hadoop-hdfs/src/site/apt/ShortCircuitLocalReads.apt.vm
>
> best,
> Colin
>
>
> On Thu, Apr 11, 2013 at 6:37 PM, Azuryy Yu <az...@gmail.com> wrote:
>
> > It's good to know HDFS-347 win the votes finally.
> >
> > Does there need some additional configuration to enable these features?
> >
> >
> >
> > On Fri, Apr 12, 2013 at 2:05 AM, Colin McCabe <cmccabe@alumni.cmu.edu
> > >wrote:
> >
> > > The merge vote is now closed. With three +1s, it passes.
> > >
> > > thanks,
> > > Colin
> > >
> > >
> > > On Wed, Apr 10, 2013 at 10:00 PM, Aaron T. Myers <at...@cloudera.com>
> > wrote:
> > >
> > > > I'm +1 as well. I've reviewed much of the code as well and have
> > > personally
> > > > seen it running in production at several different sites. I agree
> with
> > > Todd
> > > > that it's a substantial improvement in operability.
> > > >
> > > > Best,
> > > > Aaron
> > > >
> > > > On Apr 8, 2013, at 1:19 PM, Todd Lipcon <to...@cloudera.com> wrote:
> > > >
> > > > > +1 for the branch merge. I've reviewed all of the code in the
> branch,
> > > and
> > > > > we have people now running this code in production scenarios. It is
> > as
> > > > > functional as the old version and way easier to set up/configure.
> > > > >
> > > > > -Todd
> > > > >
> > > > > On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <
> cmccabe@alumni.cmu.edu
> > >
> > > > wrote:
> > > > >
> > > > >> Hi all,
> > > > >>
> > > > >> I think it's time to merge the HDFS-347 branch back to trunk.
> It's
> > > been
> > > > >> under
> > > > >> review and testing for several months, and provides both a
> > performance
> > > > >> advantage, and the ability to use short-circuit local reads
> without
> > > > >> compromising system security.
> > > > >>
> > > > >> Previously, we tried to merge this and the objection was brought
> up
> > > > that we
> > > > >> should keep the old, insecure short-circuit local reads around so
> > that
> > > > >> platforms for which secure SCR had not yet been implemented could
> > use
> > > it
> > > > >> (e.g. Windows). This has been addressed-- see HDFS-4538 for
> > details.
> > > > >> Suresh has also volunteered to maintain the insecure SCR code
> until
> > > > secure
> > > > >> SCR can be implemented for Windows.
> > > > >>
> > > > >> Please cast your vote by EOD Monday 4/8.
> > > > >>
> > > > >> best,
> > > > >> Colin
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Todd Lipcon
> > > > > Software Engineer, Cloudera
> > > >
> > >
> >
>
Re: VOTE: HDFS-347 merge
Posted by Colin McCabe <cm...@alumni.cmu.edu>.
Hi Azuryy,
The branch adds new APT documentation which describes the new configuration
that is needed.
It's
in ./hadoop-hdfs-project/hadoop-hdfs/src/site/apt/ShortCircuitLocalReads.apt.vm
best,
Colin
On Thu, Apr 11, 2013 at 6:37 PM, Azuryy Yu <az...@gmail.com> wrote:
> It's good to know HDFS-347 win the votes finally.
>
> Does there need some additional configuration to enable these features?
>
>
>
> On Fri, Apr 12, 2013 at 2:05 AM, Colin McCabe <cmccabe@alumni.cmu.edu
> >wrote:
>
> > The merge vote is now closed. With three +1s, it passes.
> >
> > thanks,
> > Colin
> >
> >
> > On Wed, Apr 10, 2013 at 10:00 PM, Aaron T. Myers <at...@cloudera.com>
> wrote:
> >
> > > I'm +1 as well. I've reviewed much of the code as well and have
> > personally
> > > seen it running in production at several different sites. I agree with
> > Todd
> > > that it's a substantial improvement in operability.
> > >
> > > Best,
> > > Aaron
> > >
> > > On Apr 8, 2013, at 1:19 PM, Todd Lipcon <to...@cloudera.com> wrote:
> > >
> > > > +1 for the branch merge. I've reviewed all of the code in the branch,
> > and
> > > > we have people now running this code in production scenarios. It is
> as
> > > > functional as the old version and way easier to set up/configure.
> > > >
> > > > -Todd
> > > >
> > > > On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cmccabe@alumni.cmu.edu
> >
> > > wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> I think it's time to merge the HDFS-347 branch back to trunk. It's
> > been
> > > >> under
> > > >> review and testing for several months, and provides both a
> performance
> > > >> advantage, and the ability to use short-circuit local reads without
> > > >> compromising system security.
> > > >>
> > > >> Previously, we tried to merge this and the objection was brought up
> > > that we
> > > >> should keep the old, insecure short-circuit local reads around so
> that
> > > >> platforms for which secure SCR had not yet been implemented could
> use
> > it
> > > >> (e.g. Windows). This has been addressed-- see HDFS-4538 for
> details.
> > > >> Suresh has also volunteered to maintain the insecure SCR code until
> > > secure
> > > >> SCR can be implemented for Windows.
> > > >>
> > > >> Please cast your vote by EOD Monday 4/8.
> > > >>
> > > >> best,
> > > >> Colin
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Todd Lipcon
> > > > Software Engineer, Cloudera
> > >
> >
>
Re: VOTE: HDFS-347 merge
Posted by Azuryy Yu <az...@gmail.com>.
It's good to know HDFS-347 win the votes finally.
Does there need some additional configuration to enable these features?
On Fri, Apr 12, 2013 at 2:05 AM, Colin McCabe <cm...@alumni.cmu.edu>wrote:
> The merge vote is now closed. With three +1s, it passes.
>
> thanks,
> Colin
>
>
> On Wed, Apr 10, 2013 at 10:00 PM, Aaron T. Myers <at...@cloudera.com> wrote:
>
> > I'm +1 as well. I've reviewed much of the code as well and have
> personally
> > seen it running in production at several different sites. I agree with
> Todd
> > that it's a substantial improvement in operability.
> >
> > Best,
> > Aaron
> >
> > On Apr 8, 2013, at 1:19 PM, Todd Lipcon <to...@cloudera.com> wrote:
> >
> > > +1 for the branch merge. I've reviewed all of the code in the branch,
> and
> > > we have people now running this code in production scenarios. It is as
> > > functional as the old version and way easier to set up/configure.
> > >
> > > -Todd
> > >
> > > On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cm...@alumni.cmu.edu>
> > wrote:
> > >
> > >> Hi all,
> > >>
> > >> I think it's time to merge the HDFS-347 branch back to trunk. It's
> been
> > >> under
> > >> review and testing for several months, and provides both a performance
> > >> advantage, and the ability to use short-circuit local reads without
> > >> compromising system security.
> > >>
> > >> Previously, we tried to merge this and the objection was brought up
> > that we
> > >> should keep the old, insecure short-circuit local reads around so that
> > >> platforms for which secure SCR had not yet been implemented could use
> it
> > >> (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
> > >> Suresh has also volunteered to maintain the insecure SCR code until
> > secure
> > >> SCR can be implemented for Windows.
> > >>
> > >> Please cast your vote by EOD Monday 4/8.
> > >>
> > >> best,
> > >> Colin
> > >>
> > >
> > >
> > >
> > > --
> > > Todd Lipcon
> > > Software Engineer, Cloudera
> >
>
Re: VOTE: HDFS-347 merge
Posted by "Aaron T. Myers" <at...@cloudera.com>.
Since the merge vote passed, I have merged the HDFS-347 branch to trunk.
Leaving the JIRA open for now until we also do the merge to branch-2.
Colin, thanks a ton for the monster contribution. This is a long time in
coming.
--
Aaron T. Myers
Software Engineer, Cloudera
On Thu, Apr 11, 2013 at 11:05 AM, Colin McCabe <cm...@alumni.cmu.edu>wrote:
> The merge vote is now closed. With three +1s, it passes.
>
> thanks,
> Colin
>
>
> On Wed, Apr 10, 2013 at 10:00 PM, Aaron T. Myers <at...@cloudera.com> wrote:
>
> > I'm +1 as well. I've reviewed much of the code as well and have
> personally
> > seen it running in production at several different sites. I agree with
> Todd
> > that it's a substantial improvement in operability.
> >
> > Best,
> > Aaron
> >
> > On Apr 8, 2013, at 1:19 PM, Todd Lipcon <to...@cloudera.com> wrote:
> >
> > > +1 for the branch merge. I've reviewed all of the code in the branch,
> and
> > > we have people now running this code in production scenarios. It is as
> > > functional as the old version and way easier to set up/configure.
> > >
> > > -Todd
> > >
> > > On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cm...@alumni.cmu.edu>
> > wrote:
> > >
> > >> Hi all,
> > >>
> > >> I think it's time to merge the HDFS-347 branch back to trunk. It's
> been
> > >> under
> > >> review and testing for several months, and provides both a performance
> > >> advantage, and the ability to use short-circuit local reads without
> > >> compromising system security.
> > >>
> > >> Previously, we tried to merge this and the objection was brought up
> > that we
> > >> should keep the old, insecure short-circuit local reads around so that
> > >> platforms for which secure SCR had not yet been implemented could use
> it
> > >> (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
> > >> Suresh has also volunteered to maintain the insecure SCR code until
> > secure
> > >> SCR can be implemented for Windows.
> > >>
> > >> Please cast your vote by EOD Monday 4/8.
> > >>
> > >> best,
> > >> Colin
> > >>
> > >
> > >
> > >
> > > --
> > > Todd Lipcon
> > > Software Engineer, Cloudera
> >
>
Re: VOTE: HDFS-347 merge
Posted by Colin McCabe <cm...@alumni.cmu.edu>.
The merge vote is now closed. With three +1s, it passes.
thanks,
Colin
On Wed, Apr 10, 2013 at 10:00 PM, Aaron T. Myers <at...@cloudera.com> wrote:
> I'm +1 as well. I've reviewed much of the code as well and have personally
> seen it running in production at several different sites. I agree with Todd
> that it's a substantial improvement in operability.
>
> Best,
> Aaron
>
> On Apr 8, 2013, at 1:19 PM, Todd Lipcon <to...@cloudera.com> wrote:
>
> > +1 for the branch merge. I've reviewed all of the code in the branch, and
> > we have people now running this code in production scenarios. It is as
> > functional as the old version and way easier to set up/configure.
> >
> > -Todd
> >
> > On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cm...@alumni.cmu.edu>
> wrote:
> >
> >> Hi all,
> >>
> >> I think it's time to merge the HDFS-347 branch back to trunk. It's been
> >> under
> >> review and testing for several months, and provides both a performance
> >> advantage, and the ability to use short-circuit local reads without
> >> compromising system security.
> >>
> >> Previously, we tried to merge this and the objection was brought up
> that we
> >> should keep the old, insecure short-circuit local reads around so that
> >> platforms for which secure SCR had not yet been implemented could use it
> >> (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
> >> Suresh has also volunteered to maintain the insecure SCR code until
> secure
> >> SCR can be implemented for Windows.
> >>
> >> Please cast your vote by EOD Monday 4/8.
> >>
> >> best,
> >> Colin
> >>
> >
> >
> >
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
>
Re: VOTE: HDFS-347 merge
Posted by "Aaron T. Myers" <at...@cloudera.com>.
I'm +1 as well. I've reviewed much of the code as well and have personally seen it running in production at several different sites. I agree with Todd that it's a substantial improvement in operability.
Best,
Aaron
On Apr 8, 2013, at 1:19 PM, Todd Lipcon <to...@cloudera.com> wrote:
> +1 for the branch merge. I've reviewed all of the code in the branch, and
> we have people now running this code in production scenarios. It is as
> functional as the old version and way easier to set up/configure.
>
> -Todd
>
> On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cm...@alumni.cmu.edu> wrote:
>
>> Hi all,
>>
>> I think it's time to merge the HDFS-347 branch back to trunk. It's been
>> under
>> review and testing for several months, and provides both a performance
>> advantage, and the ability to use short-circuit local reads without
>> compromising system security.
>>
>> Previously, we tried to merge this and the objection was brought up that we
>> should keep the old, insecure short-circuit local reads around so that
>> platforms for which secure SCR had not yet been implemented could use it
>> (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
>> Suresh has also volunteered to maintain the insecure SCR code until secure
>> SCR can be implemented for Windows.
>>
>> Please cast your vote by EOD Monday 4/8.
>>
>> best,
>> Colin
>>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
Re: VOTE: HDFS-347 merge
Posted by Todd Lipcon <to...@cloudera.com>.
+1 for the branch merge. I've reviewed all of the code in the branch, and
we have people now running this code in production scenarios. It is as
functional as the old version and way easier to set up/configure.
-Todd
On Mon, Apr 1, 2013 at 4:32 PM, Colin McCabe <cm...@alumni.cmu.edu> wrote:
> Hi all,
>
> I think it's time to merge the HDFS-347 branch back to trunk. It's been
> under
> review and testing for several months, and provides both a performance
> advantage, and the ability to use short-circuit local reads without
> compromising system security.
>
> Previously, we tried to merge this and the objection was brought up that we
> should keep the old, insecure short-circuit local reads around so that
> platforms for which secure SCR had not yet been implemented could use it
> (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
> Suresh has also volunteered to maintain the insecure SCR code until secure
> SCR can be implemented for Windows.
>
> Please cast your vote by EOD Monday 4/8.
>
> best,
> Colin
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: VOTE: HDFS-347 merge
Posted by Todd Lipcon <to...@cloudera.com>.
On Thu, Apr 4, 2013 at 9:11 PM, Tsz Wo Sze <sz...@yahoo.com> wrote:
> Colin,
>
> We usually conclude the last VOTE before starting a new one. Otherwise,
> people may be confused between the VOTEs. (In case you don't know our
> convention. Please check with someone before starting a VOTE. Thanks.)
>
>
> -1
> * The previous VOTE started by Colin has not been concluded.
>
I can't tell if you're being serious about this... April fools was a few
days ago. This is ridiculous - the previous vote was called 2/17 and
explicitly said it was ending on 2/24. Do you think anyone's confused about
which vote is active a month and a half later?
>
> * The branch is not ready. The code misuses DataTransferProtocol.
> Documentation of the new conf properties are missing. Also, the code in
> the branch needs to be polished. See HDFS-347 and HDFS-4661 for more
> details.
>
During the last vote thread, both you and Suresh said you'd actively review
the changes Colin made in response to your review feedback. Then, after
Colin posted a patch to address your complaints, it sat unreviewed for a
month before I reviewed and committed it. Now, Colin calls another vote,
and you find more nit picks in the branch, which again are not new code and
have been there for months.
I don't see how you can possibly think this is a reasonable way of going
about your duties as a reviewer of the branch, nor why you are voting -1
due to a few small nits in the codebase. Actions like these limit the
growth of our contributor base and discourage others from joining our
development community -- I for one am quite impressed with Colin's patience
throughout this ridiculous ordeal, but many others wouldn't have the same
fortitude.
If you find issues with the branch, put up a patch and let's get on with
it. This back-and-forthing is wasting all of our time.
Todd
>
> ________________________________
> From: Colin McCabe <cm...@alumni.cmu.edu>
> To: hdfs-dev@hadoop.apache.org
> Sent: Tuesday, April 2, 2013 7:32 AM
> Subject: VOTE: HDFS-347 merge
>
> Hi all,
>
> I think it's time to merge the HDFS-347 branch back to trunk. It's been
> under
> review and testing for several months, and provides both a performance
> advantage, and the ability to use short-circuit local reads without
> compromising system security.
>
> Previously, we tried to merge this and the objection was brought up that we
> should keep the old, insecure short-circuit local reads around so that
> platforms for which secure SCR had not yet been implemented could use it
> (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
> Suresh has also volunteered to maintain the insecure SCR code until secure
> SCR can be implemented for Windows.
>
> Please cast your vote by EOD Monday 4/8.
>
> best,
> Colin
>
--
Todd Lipcon
Software Engineer, Cloudera
Re: VOTE: HDFS-347 merge
Posted by Suresh Srinivas <su...@hortonworks.com>.
> We usually conclude the last VOTE before starting a new one. Otherwise,
> people may be confused between the VOTEs. (In case you don't know our
> convention. Please check with someone before starting a VOTE. Thanks.)
>
>
> -1
> * The previous VOTE started by Colin has not been concluded.
>
Nicholas, given that the two voting threads are far apart in time, lets
keep this voting thread alive. So please consider withdrawing -1 on the
basis of this technical reason.
>
> * The branch is not ready. The code misuses DataTransferProtocol.
> Documentation of the new conf properties are missing. Also, the code in
> the branch needs to be polished. See HDFS-347 and HDFS-4661 for more
> details.
>
Do you think these cannot be worked on trunk. I think waiting for all the
things complete in a feature branch might slowdown feature development. I
think some of these issues can be addressed in trunk. We could also
consider waiting for all the issues that you have brought up to be
addressed before merging it to the branch-2. Please do post a comment on
HDFS-347 on which of the issues should be addressed before merging to
branch-2.
> Tsz-Wo
>
>
>
> ________________________________
> From: Colin McCabe <cm...@alumni.cmu.edu>
> To: hdfs-dev@hadoop.apache.org
> Sent: Tuesday, April 2, 2013 7:32 AM
> Subject: VOTE: HDFS-347 merge
>
> Hi all,
>
> I think it's time to merge the HDFS-347 branch back to trunk. It's been
> under
> review and testing for several months, and provides both a performance
> advantage, and the ability to use short-circuit local reads without
> compromising system security.
>
> Previously, we tried to merge this and the objection was brought up that we
> should keep the old, insecure short-circuit local reads around so that
> platforms for which secure SCR had not yet been implemented could use it
> (e.g. Windows). This has been addressed-- see HDFS-4538 for details.
> Suresh has also volunteered to maintain the insecure SCR code until secure
> SCR can be implemented for Windows.
>
> Please cast your vote by EOD Monday 4/8.
>
> best,
> Colin
>
--
http://hortonworks.com/download/
Re: VOTE: HDFS-347 merge
Posted by Tsz Wo Sze <sz...@yahoo.com>.
Hi Colin,
Thanks for closing the previous VOTE. (We usually count the numbers of +1's and -1's, and then state whether the vote passes. Hope that you could include such information next time.)
I withdraw my -1.
Tsz-Wo
________________________________
From: Tsz Wo Sze <sz...@yahoo.com>
To: "hdfs-dev@hadoop.apache.org" <hd...@hadoop.apache.org>
Sent: Sunday, April 7, 2013 8:01 AM
Subject: Re: VOTE: HDFS-347 merge
The patch in HDFS-4661 has addressed the problem I raised. Once the previous VOTE has be concluded, I will remove my -1. Thanks.
Tsz-Wo
________________________________
From: Tsz Wo Sze <sz...@yahoo.com>
To: "hdfs-dev@hadoop.apache.org" <hd...@hadoop.apache.org>
Sent: Friday, April 5, 2013 12:11 PM
Subject: Re: VOTE: HDFS-347 merge
Colin,
We usually conclude the last VOTE before starting a new one. Otherwise, people may be confused between the VOTEs. (In case you don't know our convention. Please check with someone before starting a VOTE. Thanks.)
-1
* The previous VOTE started by Colin has not been concluded.
* The branch is not ready. The code misuses DataTransferProtocol. Documentation of the new conf properties are missing. Also, the code in the branch needs to be polished. See HDFS-347 and HDFS-4661 for more details.
Tsz-Wo
________________________________
From: Colin McCabe <cm...@alumni.cmu.edu>
To: hdfs-dev@hadoop.apache.org
Sent: Tuesday, April 2, 2013 7:32 AM
Subject: VOTE:
HDFS-347 merge
Hi all,
I think it's time to merge the HDFS-347 branch back to trunk. It's been under
review and testing for several months, and provides both a performance
advantage, and the ability to use short-circuit local reads without
compromising system security.
Previously, we tried to merge this and the objection was brought up that we
should keep the old, insecure short-circuit local reads around so that
platforms for which secure SCR had not yet been implemented could use it
(e.g. Windows). This has been addressed-- see HDFS-4538 for details.
Suresh has also volunteered to maintain the insecure SCR code until secure
SCR can be implemented for Windows.
Please cast your vote by EOD Monday 4/8.
best,
Colin
Re: VOTE: HDFS-347 merge
Posted by Tsz Wo Sze <sz...@yahoo.com>.
The patch in HDFS-4661 has addressed the problem I raised. Once the previous VOTE has be concluded, I will remove my -1. Thanks.
Tsz-Wo
________________________________
From: Tsz Wo Sze <sz...@yahoo.com>
To: "hdfs-dev@hadoop.apache.org" <hd...@hadoop.apache.org>
Sent: Friday, April 5, 2013 12:11 PM
Subject: Re: VOTE: HDFS-347 merge
Colin,
We usually conclude the last VOTE before starting a new one. Otherwise, people may be confused between the VOTEs. (In case you don't know our convention. Please check with someone before starting a VOTE. Thanks.)
-1
* The previous VOTE started by Colin has not been concluded.
* The branch is not ready. The code misuses DataTransferProtocol. Documentation of the new conf properties are missing. Also, the code in the branch needs to be polished. See HDFS-347 and HDFS-4661 for more details.
Tsz-Wo
________________________________
From: Colin McCabe <cm...@alumni.cmu.edu>
To: hdfs-dev@hadoop.apache.org
Sent: Tuesday, April 2, 2013 7:32 AM
Subject: VOTE: HDFS-347 merge
Hi all,
I think it's time to merge the HDFS-347 branch back to trunk. It's been under
review and testing for several months, and provides both a performance
advantage, and the ability to use short-circuit local reads without
compromising system security.
Previously, we tried to merge this and the objection was brought up that we
should keep the old, insecure short-circuit local reads around so that
platforms for which secure SCR had not yet been implemented could use it
(e.g. Windows). This has been addressed-- see HDFS-4538 for details.
Suresh has also volunteered to maintain the insecure SCR code until secure
SCR can be implemented for Windows.
Please cast your vote by EOD Monday 4/8.
best,
Colin
Re: VOTE: HDFS-347 merge
Posted by Tsz Wo Sze <sz...@yahoo.com>.
Colin,
We usually conclude the last VOTE before starting a new one. Otherwise, people may be confused between the VOTEs. (In case you don't know our convention. Please check with someone before starting a VOTE. Thanks.)
-1
* The previous VOTE started by Colin has not been concluded.
* The branch is not ready. The code misuses DataTransferProtocol. Documentation of the new conf properties are missing. Also, the code in the branch needs to be polished. See HDFS-347 and HDFS-4661 for more details.
Tsz-Wo
________________________________
From: Colin McCabe <cm...@alumni.cmu.edu>
To: hdfs-dev@hadoop.apache.org
Sent: Tuesday, April 2, 2013 7:32 AM
Subject: VOTE: HDFS-347 merge
Hi all,
I think it's time to merge the HDFS-347 branch back to trunk. It's been under
review and testing for several months, and provides both a performance
advantage, and the ability to use short-circuit local reads without
compromising system security.
Previously, we tried to merge this and the objection was brought up that we
should keep the old, insecure short-circuit local reads around so that
platforms for which secure SCR had not yet been implemented could use it
(e.g. Windows). This has been addressed-- see HDFS-4538 for details.
Suresh has also volunteered to maintain the insecure SCR code until secure
SCR can be implemented for Windows.
Please cast your vote by EOD Monday 4/8.
best,
Colin