You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-dev@hadoop.apache.org by Wangda Tan <wh...@gmail.com> on 2017/08/18 03:27:53 UTC
Re: [DISCUSS] Merge YARN resource profile (YARN-3926) branch into trunk
+hdfs/common/mr
On Thu, Aug 17, 2017 at 1:28 PM, Wangda Tan <wh...@gmail.com> wrote:
> Hi all,
>
> I want to hear your thoughts of merging YARN resource profile branch into
> trunk in the next few weeks. The goal is to get it in for Hadoop 3.0 beta1.
>
> *Regarding to testing:*
> We did extensive tests for the feature in the last several months.
> Comparing to latest trunk.
> - For SLS benchmark: We didn't see observable performance gap from
> simulated test based on 8K nodes SLS traces (1 PB memory). We got 3k+
> containers allocated per second.
> - For microbenchmark: We use performance test cases added by YARN-6775, it
> shows around 5% performance regression comparing to trunk.
>
> *Regarding to API stability: *
> Most new added @Public APIs are @Unstable (We're going to convert some new
> added @Public/@Evolving to @Unstable in the cleanup JIRA as well), we want
> to get this included by beta1 so we get some feedbacks before declaring
> stable API.
>
> There're few pending cleanups under YARN-3926 umbrella JIRA. Besides these
> cleanups, this feature works from end-to-end, we will do another iteration
> of end-to-end tests after cleanup patches got committed.
>
> We would love to get your thoughts before opening a voting thread.
>
> Special thanks to a team of folks who worked hard and contributed towards
> this efforts including design discussion / patch / reviews, etc.: Varun
> Vasudev, Sunil Govind, Daniel Templeton, Vinod Vavilapalli, Yufei Gu,
> Karthik Kambatla, Jason Lowe, Arun Suresh.
>
> Thanks,
> Wangda Tan
>
Re: [DISCUSS] Merge YARN resource profile (YARN-3926) branch into trunk
Posted by Wangda Tan <wh...@gmail.com>.
Hi Andrew,
This feature can be disabled, It is off by default. The major change of
existing code path it Resource YARN PB record related implementations, we
did lots of tests around this regarding to performances and safety of these
changes, so far so good (please refer to my email regarding to performance
and compatibility). Beyond resource PB implementation changes, it mostly
add new code path instead of modifying existing logics. We will continue to
do more verifications next week to minimize risks.
As I mentioned, new added fields are marked as Unstable right now (and we
will convert some @evolving to @unstable). They're all stated in javadocs.
I completely understand the recent emerging merge request makes everybody
nervous, we will try to do more tests and move fast to meet the time line.
:)
Please let me know if you have any other concerns.
Thanks,
Wangda
On Fri, Aug 18, 2017 at 2:34 PM, Andrew Wang <an...@cloudera.com>
wrote:
> Hi Wangda,
>
> Can this feature be disabled? Is it on or off by default? We're 1 month
> from the target release for beta1, so I don't want to introduce risk to
> existing code paths. TSv2 and S3Guard and YARN Federation are all okay in
> that regard.
>
> I'm also not clear on what work is remaining, there are a lot of
> unresolved subtasks still under YARN-3926.
>
> In terms of compatibility, the design doc talks about some PB changes. Are
> these stable? Is there documentation somewhere that explains what APIs are
> stable or unstable for users?
>
> I'm going to start a separate discussion about beta1 scope. I think this
> is the fourth merge proposal this week, and this amount of code movement
> makes me very nervous considering that beta1 is only a month out.
>
> Best,
> Andrew
>
> On Thu, Aug 17, 2017 at 8:27 PM, Wangda Tan <wh...@gmail.com> wrote:
>
>> +hdfs/common/mr
>>
>> On Thu, Aug 17, 2017 at 1:28 PM, Wangda Tan <wh...@gmail.com> wrote:
>>
>> > Hi all,
>> >
>> > I want to hear your thoughts of merging YARN resource profile branch
>> into
>> > trunk in the next few weeks. The goal is to get it in for Hadoop 3.0
>> beta1.
>> >
>> > *Regarding to testing:*
>> > We did extensive tests for the feature in the last several months.
>> > Comparing to latest trunk.
>> > - For SLS benchmark: We didn't see observable performance gap from
>> > simulated test based on 8K nodes SLS traces (1 PB memory). We got 3k+
>> > containers allocated per second.
>> > - For microbenchmark: We use performance test cases added by YARN-6775,
>> it
>> > shows around 5% performance regression comparing to trunk.
>> >
>> > *Regarding to API stability: *
>> > Most new added @Public APIs are @Unstable (We're going to convert some
>> new
>> > added @Public/@Evolving to @Unstable in the cleanup JIRA as well), we
>> want
>> > to get this included by beta1 so we get some feedbacks before declaring
>> > stable API.
>> >
>> > There're few pending cleanups under YARN-3926 umbrella JIRA. Besides
>> these
>> > cleanups, this feature works from end-to-end, we will do another
>> iteration
>> > of end-to-end tests after cleanup patches got committed.
>> >
>> > We would love to get your thoughts before opening a voting thread.
>> >
>> > Special thanks to a team of folks who worked hard and contributed
>> towards
>> > this efforts including design discussion / patch / reviews, etc.: Varun
>> > Vasudev, Sunil Govind, Daniel Templeton, Vinod Vavilapalli, Yufei Gu,
>> > Karthik Kambatla, Jason Lowe, Arun Suresh.
>> >
>> > Thanks,
>> > Wangda Tan
>> >
>>
>
>
Re: [DISCUSS] Merge YARN resource profile (YARN-3926) branch into trunk
Posted by Wangda Tan <wh...@gmail.com>.
Hi Andrew,
This feature can be disabled, It is off by default. The major change of
existing code path it Resource YARN PB record related implementations, we
did lots of tests around this regarding to performances and safety of these
changes, so far so good (please refer to my email regarding to performance
and compatibility). Beyond resource PB implementation changes, it mostly
add new code path instead of modifying existing logics. We will continue to
do more verifications next week to minimize risks.
As I mentioned, new added fields are marked as Unstable right now (and we
will convert some @evolving to @unstable). They're all stated in javadocs.
I completely understand the recent emerging merge request makes everybody
nervous, we will try to do more tests and move fast to meet the time line.
:)
Please let me know if you have any other concerns.
Thanks,
Wangda
On Fri, Aug 18, 2017 at 2:34 PM, Andrew Wang <an...@cloudera.com>
wrote:
> Hi Wangda,
>
> Can this feature be disabled? Is it on or off by default? We're 1 month
> from the target release for beta1, so I don't want to introduce risk to
> existing code paths. TSv2 and S3Guard and YARN Federation are all okay in
> that regard.
>
> I'm also not clear on what work is remaining, there are a lot of
> unresolved subtasks still under YARN-3926.
>
> In terms of compatibility, the design doc talks about some PB changes. Are
> these stable? Is there documentation somewhere that explains what APIs are
> stable or unstable for users?
>
> I'm going to start a separate discussion about beta1 scope. I think this
> is the fourth merge proposal this week, and this amount of code movement
> makes me very nervous considering that beta1 is only a month out.
>
> Best,
> Andrew
>
> On Thu, Aug 17, 2017 at 8:27 PM, Wangda Tan <wh...@gmail.com> wrote:
>
>> +hdfs/common/mr
>>
>> On Thu, Aug 17, 2017 at 1:28 PM, Wangda Tan <wh...@gmail.com> wrote:
>>
>> > Hi all,
>> >
>> > I want to hear your thoughts of merging YARN resource profile branch
>> into
>> > trunk in the next few weeks. The goal is to get it in for Hadoop 3.0
>> beta1.
>> >
>> > *Regarding to testing:*
>> > We did extensive tests for the feature in the last several months.
>> > Comparing to latest trunk.
>> > - For SLS benchmark: We didn't see observable performance gap from
>> > simulated test based on 8K nodes SLS traces (1 PB memory). We got 3k+
>> > containers allocated per second.
>> > - For microbenchmark: We use performance test cases added by YARN-6775,
>> it
>> > shows around 5% performance regression comparing to trunk.
>> >
>> > *Regarding to API stability: *
>> > Most new added @Public APIs are @Unstable (We're going to convert some
>> new
>> > added @Public/@Evolving to @Unstable in the cleanup JIRA as well), we
>> want
>> > to get this included by beta1 so we get some feedbacks before declaring
>> > stable API.
>> >
>> > There're few pending cleanups under YARN-3926 umbrella JIRA. Besides
>> these
>> > cleanups, this feature works from end-to-end, we will do another
>> iteration
>> > of end-to-end tests after cleanup patches got committed.
>> >
>> > We would love to get your thoughts before opening a voting thread.
>> >
>> > Special thanks to a team of folks who worked hard and contributed
>> towards
>> > this efforts including design discussion / patch / reviews, etc.: Varun
>> > Vasudev, Sunil Govind, Daniel Templeton, Vinod Vavilapalli, Yufei Gu,
>> > Karthik Kambatla, Jason Lowe, Arun Suresh.
>> >
>> > Thanks,
>> > Wangda Tan
>> >
>>
>
>
Re: [DISCUSS] Merge YARN resource profile (YARN-3926) branch into trunk
Posted by Wangda Tan <wh...@gmail.com>.
Hi Andrew,
This feature can be disabled, It is off by default. The major change of
existing code path it Resource YARN PB record related implementations, we
did lots of tests around this regarding to performances and safety of these
changes, so far so good (please refer to my email regarding to performance
and compatibility). Beyond resource PB implementation changes, it mostly
add new code path instead of modifying existing logics. We will continue to
do more verifications next week to minimize risks.
As I mentioned, new added fields are marked as Unstable right now (and we
will convert some @evolving to @unstable). They're all stated in javadocs.
I completely understand the recent emerging merge request makes everybody
nervous, we will try to do more tests and move fast to meet the time line.
:)
Please let me know if you have any other concerns.
Thanks,
Wangda
On Fri, Aug 18, 2017 at 2:34 PM, Andrew Wang <an...@cloudera.com>
wrote:
> Hi Wangda,
>
> Can this feature be disabled? Is it on or off by default? We're 1 month
> from the target release for beta1, so I don't want to introduce risk to
> existing code paths. TSv2 and S3Guard and YARN Federation are all okay in
> that regard.
>
> I'm also not clear on what work is remaining, there are a lot of
> unresolved subtasks still under YARN-3926.
>
> In terms of compatibility, the design doc talks about some PB changes. Are
> these stable? Is there documentation somewhere that explains what APIs are
> stable or unstable for users?
>
> I'm going to start a separate discussion about beta1 scope. I think this
> is the fourth merge proposal this week, and this amount of code movement
> makes me very nervous considering that beta1 is only a month out.
>
> Best,
> Andrew
>
> On Thu, Aug 17, 2017 at 8:27 PM, Wangda Tan <wh...@gmail.com> wrote:
>
>> +hdfs/common/mr
>>
>> On Thu, Aug 17, 2017 at 1:28 PM, Wangda Tan <wh...@gmail.com> wrote:
>>
>> > Hi all,
>> >
>> > I want to hear your thoughts of merging YARN resource profile branch
>> into
>> > trunk in the next few weeks. The goal is to get it in for Hadoop 3.0
>> beta1.
>> >
>> > *Regarding to testing:*
>> > We did extensive tests for the feature in the last several months.
>> > Comparing to latest trunk.
>> > - For SLS benchmark: We didn't see observable performance gap from
>> > simulated test based on 8K nodes SLS traces (1 PB memory). We got 3k+
>> > containers allocated per second.
>> > - For microbenchmark: We use performance test cases added by YARN-6775,
>> it
>> > shows around 5% performance regression comparing to trunk.
>> >
>> > *Regarding to API stability: *
>> > Most new added @Public APIs are @Unstable (We're going to convert some
>> new
>> > added @Public/@Evolving to @Unstable in the cleanup JIRA as well), we
>> want
>> > to get this included by beta1 so we get some feedbacks before declaring
>> > stable API.
>> >
>> > There're few pending cleanups under YARN-3926 umbrella JIRA. Besides
>> these
>> > cleanups, this feature works from end-to-end, we will do another
>> iteration
>> > of end-to-end tests after cleanup patches got committed.
>> >
>> > We would love to get your thoughts before opening a voting thread.
>> >
>> > Special thanks to a team of folks who worked hard and contributed
>> towards
>> > this efforts including design discussion / patch / reviews, etc.: Varun
>> > Vasudev, Sunil Govind, Daniel Templeton, Vinod Vavilapalli, Yufei Gu,
>> > Karthik Kambatla, Jason Lowe, Arun Suresh.
>> >
>> > Thanks,
>> > Wangda Tan
>> >
>>
>
>
Re: [DISCUSS] Merge YARN resource profile (YARN-3926) branch into trunk
Posted by Wangda Tan <wh...@gmail.com>.
Hi Andrew,
This feature can be disabled, It is off by default. The major change of
existing code path it Resource YARN PB record related implementations, we
did lots of tests around this regarding to performances and safety of these
changes, so far so good (please refer to my email regarding to performance
and compatibility). Beyond resource PB implementation changes, it mostly
add new code path instead of modifying existing logics. We will continue to
do more verifications next week to minimize risks.
As I mentioned, new added fields are marked as Unstable right now (and we
will convert some @evolving to @unstable). They're all stated in javadocs.
I completely understand the recent emerging merge request makes everybody
nervous, we will try to do more tests and move fast to meet the time line.
:)
Please let me know if you have any other concerns.
Thanks,
Wangda
On Fri, Aug 18, 2017 at 2:34 PM, Andrew Wang <an...@cloudera.com>
wrote:
> Hi Wangda,
>
> Can this feature be disabled? Is it on or off by default? We're 1 month
> from the target release for beta1, so I don't want to introduce risk to
> existing code paths. TSv2 and S3Guard and YARN Federation are all okay in
> that regard.
>
> I'm also not clear on what work is remaining, there are a lot of
> unresolved subtasks still under YARN-3926.
>
> In terms of compatibility, the design doc talks about some PB changes. Are
> these stable? Is there documentation somewhere that explains what APIs are
> stable or unstable for users?
>
> I'm going to start a separate discussion about beta1 scope. I think this
> is the fourth merge proposal this week, and this amount of code movement
> makes me very nervous considering that beta1 is only a month out.
>
> Best,
> Andrew
>
> On Thu, Aug 17, 2017 at 8:27 PM, Wangda Tan <wh...@gmail.com> wrote:
>
>> +hdfs/common/mr
>>
>> On Thu, Aug 17, 2017 at 1:28 PM, Wangda Tan <wh...@gmail.com> wrote:
>>
>> > Hi all,
>> >
>> > I want to hear your thoughts of merging YARN resource profile branch
>> into
>> > trunk in the next few weeks. The goal is to get it in for Hadoop 3.0
>> beta1.
>> >
>> > *Regarding to testing:*
>> > We did extensive tests for the feature in the last several months.
>> > Comparing to latest trunk.
>> > - For SLS benchmark: We didn't see observable performance gap from
>> > simulated test based on 8K nodes SLS traces (1 PB memory). We got 3k+
>> > containers allocated per second.
>> > - For microbenchmark: We use performance test cases added by YARN-6775,
>> it
>> > shows around 5% performance regression comparing to trunk.
>> >
>> > *Regarding to API stability: *
>> > Most new added @Public APIs are @Unstable (We're going to convert some
>> new
>> > added @Public/@Evolving to @Unstable in the cleanup JIRA as well), we
>> want
>> > to get this included by beta1 so we get some feedbacks before declaring
>> > stable API.
>> >
>> > There're few pending cleanups under YARN-3926 umbrella JIRA. Besides
>> these
>> > cleanups, this feature works from end-to-end, we will do another
>> iteration
>> > of end-to-end tests after cleanup patches got committed.
>> >
>> > We would love to get your thoughts before opening a voting thread.
>> >
>> > Special thanks to a team of folks who worked hard and contributed
>> towards
>> > this efforts including design discussion / patch / reviews, etc.: Varun
>> > Vasudev, Sunil Govind, Daniel Templeton, Vinod Vavilapalli, Yufei Gu,
>> > Karthik Kambatla, Jason Lowe, Arun Suresh.
>> >
>> > Thanks,
>> > Wangda Tan
>> >
>>
>
>
Re: [DISCUSS] Merge YARN resource profile (YARN-3926) branch into trunk
Posted by Andrew Wang <an...@cloudera.com>.
Hi Wangda,
Can this feature be disabled? Is it on or off by default? We're 1 month
from the target release for beta1, so I don't want to introduce risk to
existing code paths. TSv2 and S3Guard and YARN Federation are all okay in
that regard.
I'm also not clear on what work is remaining, there are a lot of unresolved
subtasks still under YARN-3926.
In terms of compatibility, the design doc talks about some PB changes. Are
these stable? Is there documentation somewhere that explains what APIs are
stable or unstable for users?
I'm going to start a separate discussion about beta1 scope. I think this is
the fourth merge proposal this week, and this amount of code movement makes
me very nervous considering that beta1 is only a month out.
Best,
Andrew
On Thu, Aug 17, 2017 at 8:27 PM, Wangda Tan <wh...@gmail.com> wrote:
> +hdfs/common/mr
>
> On Thu, Aug 17, 2017 at 1:28 PM, Wangda Tan <wh...@gmail.com> wrote:
>
> > Hi all,
> >
> > I want to hear your thoughts of merging YARN resource profile branch into
> > trunk in the next few weeks. The goal is to get it in for Hadoop 3.0
> beta1.
> >
> > *Regarding to testing:*
> > We did extensive tests for the feature in the last several months.
> > Comparing to latest trunk.
> > - For SLS benchmark: We didn't see observable performance gap from
> > simulated test based on 8K nodes SLS traces (1 PB memory). We got 3k+
> > containers allocated per second.
> > - For microbenchmark: We use performance test cases added by YARN-6775,
> it
> > shows around 5% performance regression comparing to trunk.
> >
> > *Regarding to API stability: *
> > Most new added @Public APIs are @Unstable (We're going to convert some
> new
> > added @Public/@Evolving to @Unstable in the cleanup JIRA as well), we
> want
> > to get this included by beta1 so we get some feedbacks before declaring
> > stable API.
> >
> > There're few pending cleanups under YARN-3926 umbrella JIRA. Besides
> these
> > cleanups, this feature works from end-to-end, we will do another
> iteration
> > of end-to-end tests after cleanup patches got committed.
> >
> > We would love to get your thoughts before opening a voting thread.
> >
> > Special thanks to a team of folks who worked hard and contributed towards
> > this efforts including design discussion / patch / reviews, etc.: Varun
> > Vasudev, Sunil Govind, Daniel Templeton, Vinod Vavilapalli, Yufei Gu,
> > Karthik Kambatla, Jason Lowe, Arun Suresh.
> >
> > Thanks,
> > Wangda Tan
> >
>
Re: [DISCUSS] Merge YARN resource profile (YARN-3926) branch into trunk
Posted by Andrew Wang <an...@cloudera.com>.
Hi Wangda,
Can this feature be disabled? Is it on or off by default? We're 1 month
from the target release for beta1, so I don't want to introduce risk to
existing code paths. TSv2 and S3Guard and YARN Federation are all okay in
that regard.
I'm also not clear on what work is remaining, there are a lot of unresolved
subtasks still under YARN-3926.
In terms of compatibility, the design doc talks about some PB changes. Are
these stable? Is there documentation somewhere that explains what APIs are
stable or unstable for users?
I'm going to start a separate discussion about beta1 scope. I think this is
the fourth merge proposal this week, and this amount of code movement makes
me very nervous considering that beta1 is only a month out.
Best,
Andrew
On Thu, Aug 17, 2017 at 8:27 PM, Wangda Tan <wh...@gmail.com> wrote:
> +hdfs/common/mr
>
> On Thu, Aug 17, 2017 at 1:28 PM, Wangda Tan <wh...@gmail.com> wrote:
>
> > Hi all,
> >
> > I want to hear your thoughts of merging YARN resource profile branch into
> > trunk in the next few weeks. The goal is to get it in for Hadoop 3.0
> beta1.
> >
> > *Regarding to testing:*
> > We did extensive tests for the feature in the last several months.
> > Comparing to latest trunk.
> > - For SLS benchmark: We didn't see observable performance gap from
> > simulated test based on 8K nodes SLS traces (1 PB memory). We got 3k+
> > containers allocated per second.
> > - For microbenchmark: We use performance test cases added by YARN-6775,
> it
> > shows around 5% performance regression comparing to trunk.
> >
> > *Regarding to API stability: *
> > Most new added @Public APIs are @Unstable (We're going to convert some
> new
> > added @Public/@Evolving to @Unstable in the cleanup JIRA as well), we
> want
> > to get this included by beta1 so we get some feedbacks before declaring
> > stable API.
> >
> > There're few pending cleanups under YARN-3926 umbrella JIRA. Besides
> these
> > cleanups, this feature works from end-to-end, we will do another
> iteration
> > of end-to-end tests after cleanup patches got committed.
> >
> > We would love to get your thoughts before opening a voting thread.
> >
> > Special thanks to a team of folks who worked hard and contributed towards
> > this efforts including design discussion / patch / reviews, etc.: Varun
> > Vasudev, Sunil Govind, Daniel Templeton, Vinod Vavilapalli, Yufei Gu,
> > Karthik Kambatla, Jason Lowe, Arun Suresh.
> >
> > Thanks,
> > Wangda Tan
> >
>
Re: [DISCUSS] Merge YARN resource profile (YARN-3926) branch into trunk
Posted by Andrew Wang <an...@cloudera.com>.
Hi Wangda,
Can this feature be disabled? Is it on or off by default? We're 1 month
from the target release for beta1, so I don't want to introduce risk to
existing code paths. TSv2 and S3Guard and YARN Federation are all okay in
that regard.
I'm also not clear on what work is remaining, there are a lot of unresolved
subtasks still under YARN-3926.
In terms of compatibility, the design doc talks about some PB changes. Are
these stable? Is there documentation somewhere that explains what APIs are
stable or unstable for users?
I'm going to start a separate discussion about beta1 scope. I think this is
the fourth merge proposal this week, and this amount of code movement makes
me very nervous considering that beta1 is only a month out.
Best,
Andrew
On Thu, Aug 17, 2017 at 8:27 PM, Wangda Tan <wh...@gmail.com> wrote:
> +hdfs/common/mr
>
> On Thu, Aug 17, 2017 at 1:28 PM, Wangda Tan <wh...@gmail.com> wrote:
>
> > Hi all,
> >
> > I want to hear your thoughts of merging YARN resource profile branch into
> > trunk in the next few weeks. The goal is to get it in for Hadoop 3.0
> beta1.
> >
> > *Regarding to testing:*
> > We did extensive tests for the feature in the last several months.
> > Comparing to latest trunk.
> > - For SLS benchmark: We didn't see observable performance gap from
> > simulated test based on 8K nodes SLS traces (1 PB memory). We got 3k+
> > containers allocated per second.
> > - For microbenchmark: We use performance test cases added by YARN-6775,
> it
> > shows around 5% performance regression comparing to trunk.
> >
> > *Regarding to API stability: *
> > Most new added @Public APIs are @Unstable (We're going to convert some
> new
> > added @Public/@Evolving to @Unstable in the cleanup JIRA as well), we
> want
> > to get this included by beta1 so we get some feedbacks before declaring
> > stable API.
> >
> > There're few pending cleanups under YARN-3926 umbrella JIRA. Besides
> these
> > cleanups, this feature works from end-to-end, we will do another
> iteration
> > of end-to-end tests after cleanup patches got committed.
> >
> > We would love to get your thoughts before opening a voting thread.
> >
> > Special thanks to a team of folks who worked hard and contributed towards
> > this efforts including design discussion / patch / reviews, etc.: Varun
> > Vasudev, Sunil Govind, Daniel Templeton, Vinod Vavilapalli, Yufei Gu,
> > Karthik Kambatla, Jason Lowe, Arun Suresh.
> >
> > Thanks,
> > Wangda Tan
> >
>
Re: [DISCUSS] Merge YARN resource profile (YARN-3926) branch into trunk
Posted by Andrew Wang <an...@cloudera.com>.
Hi Wangda,
Can this feature be disabled? Is it on or off by default? We're 1 month
from the target release for beta1, so I don't want to introduce risk to
existing code paths. TSv2 and S3Guard and YARN Federation are all okay in
that regard.
I'm also not clear on what work is remaining, there are a lot of unresolved
subtasks still under YARN-3926.
In terms of compatibility, the design doc talks about some PB changes. Are
these stable? Is there documentation somewhere that explains what APIs are
stable or unstable for users?
I'm going to start a separate discussion about beta1 scope. I think this is
the fourth merge proposal this week, and this amount of code movement makes
me very nervous considering that beta1 is only a month out.
Best,
Andrew
On Thu, Aug 17, 2017 at 8:27 PM, Wangda Tan <wh...@gmail.com> wrote:
> +hdfs/common/mr
>
> On Thu, Aug 17, 2017 at 1:28 PM, Wangda Tan <wh...@gmail.com> wrote:
>
> > Hi all,
> >
> > I want to hear your thoughts of merging YARN resource profile branch into
> > trunk in the next few weeks. The goal is to get it in for Hadoop 3.0
> beta1.
> >
> > *Regarding to testing:*
> > We did extensive tests for the feature in the last several months.
> > Comparing to latest trunk.
> > - For SLS benchmark: We didn't see observable performance gap from
> > simulated test based on 8K nodes SLS traces (1 PB memory). We got 3k+
> > containers allocated per second.
> > - For microbenchmark: We use performance test cases added by YARN-6775,
> it
> > shows around 5% performance regression comparing to trunk.
> >
> > *Regarding to API stability: *
> > Most new added @Public APIs are @Unstable (We're going to convert some
> new
> > added @Public/@Evolving to @Unstable in the cleanup JIRA as well), we
> want
> > to get this included by beta1 so we get some feedbacks before declaring
> > stable API.
> >
> > There're few pending cleanups under YARN-3926 umbrella JIRA. Besides
> these
> > cleanups, this feature works from end-to-end, we will do another
> iteration
> > of end-to-end tests after cleanup patches got committed.
> >
> > We would love to get your thoughts before opening a voting thread.
> >
> > Special thanks to a team of folks who worked hard and contributed towards
> > this efforts including design discussion / patch / reviews, etc.: Varun
> > Vasudev, Sunil Govind, Daniel Templeton, Vinod Vavilapalli, Yufei Gu,
> > Karthik Kambatla, Jason Lowe, Arun Suresh.
> >
> > Thanks,
> > Wangda Tan
> >
>