[jira] [Created] (YARN-5516) REST API changes for periodicity

[Sangeetha Abdu Jyothi (JIRA)]

Sangeetha Abdu Jyothi created YARN-5516:
---

 Summary: REST API changes for periodicity
 Key: YARN-5516
 URL: https://issues.apache.org/jira/browse/YARN-5516
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Sangeetha Abdu Jyothi
Assignee: Sangeetha Abdu Jyothi






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Created] (YARN-5515) Compatibility Docs should clarify the policy for what takes precedence when a conflict is found

[Robert Kanter (JIRA)]

Robert Kanter created YARN-5515:
---

 Summary: Compatibility Docs should clarify the policy for what 
takes precedence when a conflict is found
 Key: YARN-5515
 URL: https://issues.apache.org/jira/browse/YARN-5515
 Project: Hadoop YARN
  Issue Type: Task
  Components: documentation
Affects Versions: 2.7.2
Reporter: Robert Kanter


The Compatibility Docs 
(https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-common/Compatibility.html#Java_API)
 list the policies for Private, Public, not annotated, etc Classes and members, 
but it doesn't say what happens when there's a conflict.  We should try 
obviously try to avoid this situation, but it would be good to explicitly state 
what takes precedence.

As an example, until YARN-3225 made it consistent, {{RefreshNodesRequest}} 
looked like this:
{code:java}
@Private
@Stable
public abstract class RefreshNodesRequest {
  @Public
  @Stable
  public static RefreshNodesRequest newInstance() {
RefreshNodesRequest request = Records.newRecord(RefreshNodesRequest.class);
return request;
  }
}
{code}
Note that the class is marked {{\@Private}}, but the method is marked 
{{\@Public}}.

In this example, I'd say that the class level should have priority.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

Re: [Release thread] 2.6.5 release activities

[Karthik Kambatla]

Since there is sufficient interest in 2.6.5, we should probably do it. All
the reasons Allen outlines make sense.

That said, Junping brings up a very important point that we should think of
for future releases. For a new user or a user that does not directly
contribute to the project, more stable releases make it hard to pick from.

As Chris T mentioned, the notion of EOL for our releases seems like a good
idea. However, to come up with any EOLs, we need to have some sort of
cadence for the releases. While this is hard for major releases (big bang,
potentially incompatible features), it should be doable for minor releases.

How do people feel about doing a minor release every 6 months, with
follow-up maintenance releases every 2 months until the next minor and as
needed after that? That way, we could EOL a minor release a year after its
initial release? In the future, we could consider shrinking this window. In
addition to the EOL, this also makes our releases a little more predictable
for both users and vendors. Note that 2.6.0 went out almost 2 years ago and
we haven't had a new minor release in 14 months. I am happy to start
another DISCUSS thread around this if people think it is useful.

Thanks
Karthik

On Thu, Aug 11, 2016 at 12:50 PM, Allen Wittenauer  wrote:

>
> > On Aug 11, 2016, at 8:10 AM, Junping Du  wrote:
> >
> > Allen, to be clear, I am not against any branch release effort here.
> However,
>
> "I'm not an X but "
>
> > as RM for previous releases 2.6.3 and 2.6.4, I feel to have
> responsibility to take care branch-2.6 together with other RMs (Vinod and
> Sangjin) on this branch and understand current gap - especially, to get
> consensus from community on the future plan for 2.6.x.
> > Our bylaw give us freedom for anyone to do release effort, but our bylaw
> doesn't stop our rights for reasonable question/concern on any release
> plan. As you mentioned below, people can potentially fire up branch-1
> release effort. But if you call a release plan tomorrow for branch-1, I
> cannot imagine nobody will question on that effort. Isn't it?
>
> From previous discussions I've seen around releases, I
> think it would depend upon which employee from which vendor raised the
> question.
>
> > Let's keep discussions on releasing 2.6.5 more technical. IMO, to make
> 2.6.5 release more reasonable, shouldn't we check following questions first?
> > 1. Do we have any significant issues that should land on 2.6.5 comparing
> with 2.6.4?
> > 2. If so, any technical reasons (like: upgrade is not smoothly,
> performance downgrade, incompatibility with downstream projects, etc.) to
> stop our users to move from 2.6.4 to 2.7.2/2.7.3?
> > I believe having good answer on these questions can make our release
> plan more reasonable to the whole community. More thoughts?
>
> I think these questions are moot though:
>
> * Hadoop 2.6 is the last release to support JDK6.   That sort of ends any
> questions around moving to 2.7.
>
> * There are always bugs in software that can benefit from getting fixes.
> Given the JDK6 issue, yes, of course there are reasons why someone may want
> a 2.6.5.
>
> * If a company/vendor is willing to fund people to work on a release, I'd
> much rather they do that work in the ASF than off on their own somewhere.
> This way the community as a whole benefits.
>
>
>
> -
> To unsubscribe, e-mail: mapreduce-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org
>
>

Re: [Release thread] 2.6.5 release activities

[Allen Wittenauer]

> On Aug 11, 2016, at 8:10 AM, Junping Du  wrote:
> 
> Allen, to be clear, I am not against any branch release effort here. However,

"I'm not an X but "

> as RM for previous releases 2.6.3 and 2.6.4, I feel to have responsibility to 
> take care branch-2.6 together with other RMs (Vinod and Sangjin) on this 
> branch and understand current gap - especially, to get consensus from 
> community on the future plan for 2.6.x.
> Our bylaw give us freedom for anyone to do release effort, but our bylaw 
> doesn't stop our rights for reasonable question/concern on any release plan. 
> As you mentioned below, people can potentially fire up branch-1 release 
> effort. But if you call a release plan tomorrow for branch-1, I cannot 
> imagine nobody will question on that effort. Isn't it? 

From previous discussions I've seen around releases, I think it 
would depend upon which employee from which vendor raised the question.

> Let's keep discussions on releasing 2.6.5 more technical. IMO, to make 2.6.5 
> release more reasonable, shouldn't we check following questions first?
> 1. Do we have any significant issues that should land on 2.6.5 comparing with 
> 2.6.4?
> 2. If so, any technical reasons (like: upgrade is not smoothly, performance 
> downgrade, incompatibility with downstream projects, etc.) to stop our users 
> to move from 2.6.4 to 2.7.2/2.7.3?
> I believe having good answer on these questions can make our release plan 
> more reasonable to the whole community. More thoughts?

I think these questions are moot though:

* Hadoop 2.6 is the last release to support JDK6.   That sort of ends any 
questions around moving to 2.7. 

* There are always bugs in software that can benefit from getting fixes.  Given 
the JDK6 issue, yes, of course there are reasons why someone may want a 2.6.5.

* If a company/vendor is willing to fund people to work on a release, I'd much 
rather they do that work in the ASF than off on their own somewhere.  This way 
the community as a whole benefits.



-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Created] (YARN-5513) Move Java only tests from slider develop to yarn-native-services

[Gour Saha (JIRA)]

Gour Saha created YARN-5513:
---

 Summary: Move Java only tests from slider develop to 
yarn-native-services
 Key: YARN-5513
 URL: https://issues.apache.org/jira/browse/YARN-5513
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Gour Saha






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

YARN Contributor Meetup - 8/25

[Karthik Kambatla]

Hi folks

You are all cordially invited to the YARN contributor meetup at Cloudera on
8/25. There will be a webex for folks who can't make it in person.

Please RSVP - http://www.meetup.com/Hadoop-Contributors/events/233285258/

Thanks
Karthik

[jira] [Created] (YARN-5512) Finished containers for running application should be displayed on container table

[Rohith Sharma K S (JIRA)]

Rohith Sharma K S created YARN-5512:
---

 Summary: Finished containers for running application should be 
displayed on container table
 Key: YARN-5512
 URL: https://issues.apache.org/jira/browse/YARN-5512
 Project: Hadoop YARN
  Issue Type: Sub-task
Reporter: Rohith Sharma K S


In offline discussion with [~vinodkv], one of the point on yarn-web-ui 
improvement is, 
Currently yarn-web-ui attempt page displays running container details. But 
these container disappear once it got finished. Earlier there was no mechanism 
to track finished container details. Now, once ATSv2 is ready, finished 
containers are being published from NodeManager and can be read. It would be 
good if finished containers details also displayed. 
In new RM web ui , better if we can consider this also.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

[jira] [Created] (YARN-5511) Log refactoring: method invocation should be replaced by variable in yarn server

[Nemo Chen (JIRA)]

Nemo Chen created YARN-5511:
---

 Summary: Log refactoring: method invocation should be replaced by 
variable in yarn server
 Key: YARN-5511
 URL: https://issues.apache.org/jira/browse/YARN-5511
 Project: Hadoop YARN
  Issue Type: Bug
Affects Versions: 2.7.2
Reporter: Nemo Chen


Similar to the fix for HDFS-409. In file:

hadoop-rel-release-2.7.2/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager/src/main/java/org/apache/hadoop/yarn/server/nodemanager/security/NMTokenSecretManagerInNM.java

{code:borderStyle=solid}
...
ApplicationAttemptId appAttemptId = identifier.getApplicationAttemptId();
...
LOG.debug("NMToken key updated for application attempt : "
  + identifier.getApplicationAttemptId().toString());
{code}

In line 226, the method invocation 
identifier.getApplicationAttemptId().toString()) can be replaced by 
appAttemptId.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

Re: [Release thread] 2.6.5 release activities

[Junping Du]

Allen, to be clear, I am not against any branch release effort here. However, 
as RM for previous releases 2.6.3 and 2.6.4, I feel to have responsibility to 
take care branch-2.6 together with other RMs (Vinod and Sangjin) on this branch 
and understand current gap - especially, to get consensus from community on the 
future plan for 2.6.x.
Our bylaw give us freedom for anyone to do release effort, but our bylaw 
doesn't stop our rights for reasonable question/concern on any release plan. As 
you mentioned below, people can potentially fire up branch-1 release effort. 
But if you call a release plan tomorrow for branch-1, I cannot imagine nobody 
will question on that effort. Isn't it? 
Let's keep discussions on releasing 2.6.5 more technical. IMO, to make 2.6.5 
release more reasonable, shouldn't we check following questions first?
1. Do we have any significant issues that should land on 2.6.5 comparing with 
2.6.4?
2. If so, any technical reasons (like: upgrade is not smoothly, performance 
downgrade, incompatibility with downstream projects, etc.) to stop our users to 
move from 2.6.4 to 2.7.2/2.7.3?
I believe having good answer on these questions can make our release plan more 
reasonable to the whole community. More thoughts?

Thanks,

Junping

From: Allen Wittenauer 
Sent: Thursday, August 11, 2016 3:13 PM
To: Junping Du
Cc: common-...@hadoop.apache.org; hdfs-...@hadoop.apache.org; 
mapreduce-...@hadoop.apache.org; yarn-dev@hadoop.apache.org
Subject: Re: [Release thread] 2.6.5 release activities

> On Aug 11, 2016, at 5:59 AM, Junping Du  wrote:
>
>  These comments are more like wishes but not giving more clarifications 
> on the needs. I would like to hear more specific reasons to not move to 2.7.x 
> releases but prefer to upgrade to 2.6.5. If the only reason is about 
> expectation management, I think we should claim 2.6.5 is the last branch-2.6 
> release after this release work, otherwise people would expect us to maintain 
> this branch forever which is impossible and unnecessary. Thoughts?

The bylaws[*] are such that if community members want to spend their 
time working on a branch, there isn't much to prevent that other than the PMC 
voting down the release of that branch or removing the committers working on 
that branch.  As has been pointed out to me many times, one can't dictate where 
others spend their volunteer time.  If they want to spend their efforts on 
branch-2.6, they can.  If that comes at the detriment of releases around 
branch-2.7 or branch-2.8 or even trunk, then so be it. Technically, someone 
could still fire up a branch-1 release.  Given the numbers of committers and 
PMC members as listed on the main ASF website (not the list on project one), we 
should have more than enough people to do all this work anyway.

* - of course, there's a few bylaws that aren't really enforced, so maybe even 
this isn't true?

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

Re: Short peaks in container memory usage

[Jan Lukavský]

Hi Ravi,

I don't think cgroups will help us, because, we don't want to impose a 
hard limit on the memory usage, we just want to allow for short time 
periods, when container can consume more memory than its limit. We don't 
want to put the limit too high, because that causes underutilization of 
our cluster, but setting it "reasonable" causes applications to fail 
(because of random containers being killed because of spikes). That's 
why we created the time-window averaging resource calculator, and I was 
trying to find out, if anybody else is having similar kind of issues. If 
so, I could contribute our extension (and therefore we will not have to 
maintain it ourselves in a separate repository :)). The resource 
calculator is for hadoop 2.6, and I suppose there might be larger 
changes around this in higher versions?


Cheers,
 Jan

On 10.8.2016 19:23, Ravi Prakash wrote:

Hi Jan!

Thanks for your explanation. I'm glad that works for you! :-) 
https://issues.apache.org/jira/browse/YARN-5202 is something that 
Yahoo! talked about at the Hadoop Summit, (and it seems the community 
may be going in a similar direction, although not exactly the same.) 
There's also 
https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager/src/main/java/org/apache/hadoop/yarn/server/nodemanager/containermanager/linux/resources/CGroupsHandler.java 
. Ideally at my company we'd like memory limits also to be imposed by 
Cgroups because we have had the OOM-killer wreak havoc a couple of 
times, but from what I know, that is not an option yet.


Cheers
Ravi

On Wed, Aug 10, 2016 at 1:54 AM, Jan Lukavský 
> 
wrote:


Hi Ravi,

we don't run into situation where memory used > RAM, because
memory configured to be used by all containers on a node is less
than the total amount on memory (by a factor of say 10%). The
spikes of container memory usage, that are tolerated due to the
averaging don't happen on all containers at once, but are more of
a random nature and therefore mostly only single running container
"spikes", which therefore doesn't cause any issues. To fully
answer your question, we have overcommit enabled and therefore, if
we would run out of memory, bad things would happen. :) We are
aware of that. The risk of running into OOM-killer can be
controlled by the averaging window length - as the length grows,
the more and more spikes are tolerated. Setting the averaging
window length to 1 switches this feature off, turning it back into
the "standard" behavior, which is why I see it as a extension of
the current approach, which could be interesting to other people
as well.

  Jan


On 10.8.2016 02:48, Ravi Prakash wrote:

Hi Jan!

Thanks for your contribution. In your approach what happens when
a few containers on a node are using "excessive" memory (so that
total memory used > RAM available on the machine). Do you have
overcommit enabled?

Thanks
Ravi

On Tue, Aug 9, 2016 at 1:31 AM, Jan Lukavský
> wrote:

Hello community,

I have a question about container resource calculation in
nodemanager. Some time ago a filed JIRA
https://issues.apache.org/jira/browse/YARN-4681
, which I
though might address our problems with container being killed
because of read-only mmaping memory block. The JIRA has not
been resolved yet, but it turned out for us, that the patch
doesn't solve the problem. Some applications (namely Apache
Spark) tend to allocate really large memory blocks outside
JVM heap (using mmap, but with MAP_PRIVATE), but only for
short time periods. We solved this by creating a smoothing
resource calculator, which averages the memory usage of a
container over some time period (say 5 minutes). This
eliminates the problem of container being killed for short
memory consumption peak, but in the same time preserves the
ability to kill container that *really* consumes excessive
amount of memory.

My question is, does this seem a systematic approach to you
and should I post our patch to the community or am thinking
in a wrong direction from the beginning? :)


Thanks for reactions,

 Jan


-
To unsubscribe, e-mail:
yarn-dev-unsubscr...@hadoop.apache.org

For additional commands, e-mail:
yarn-dev-h...@hadoop.apache.org









--

Jan Lukavský
Vedoucí týmu vývoje
Seznam.cz, a.s.

Re: [Release thread] 2.6.5 release activities

[Allen Wittenauer]

> On Aug 11, 2016, at 5:59 AM, Junping Du  wrote:
> 
>  These comments are more like wishes but not giving more clarifications 
> on the needs. I would like to hear more specific reasons to not move to 2.7.x 
> releases but prefer to upgrade to 2.6.5. If the only reason is about 
> expectation management, I think we should claim 2.6.5 is the last branch-2.6 
> release after this release work, otherwise people would expect us to maintain 
> this branch forever which is impossible and unnecessary. Thoughts?

The bylaws[*] are such that if community members want to spend their 
time working on a branch, there isn't much to prevent that other than the PMC 
voting down the release of that branch or removing the committers working on 
that branch.  As has been pointed out to me many times, one can't dictate where 
others spend their volunteer time.  If they want to spend their efforts on 
branch-2.6, they can.  If that comes at the detriment of releases around 
branch-2.7 or branch-2.8 or even trunk, then so be it. Technically, someone 
could still fire up a branch-1 release.  Given the numbers of committers and 
PMC members as listed on the main ASF website (not the list on project one), we 
should have more than enough people to do all this work anyway.

* - of course, there's a few bylaws that aren't really enforced, so maybe even 
this isn't true?
-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org

Re: [Release thread] 2.6.5 release activities

[Junping Du]

Hi Chris,

  Thanks for your response!

  I think I could miss the thread discussion of "[DISCUSS] 2.6.x line 
releases" for something reason. I checked the discussion - Sean claimed that 
HBase community needs 2.6.5, Zhe said they are using 2.6.x releases and Akira 
said that are over new 50 commits land on branch-2.6 since 2.6.4. Do I miss any 
comments there?

  These comments are more like wishes but not giving more clarifications on 
the needs. I would like to hear more specific reasons to not move to 2.7.x 
releases but prefer to upgrade to 2.6.5. If the only reason is about 
expectation management, I think we should claim 2.6.5 is the last branch-2.6 
release after this release work, otherwise people would expect us to maintain 
this branch forever which is impossible and unnecessary. Thoughts?


Thanks,


Junping



From: Chris Trezzo 
Sent: Wednesday, August 10, 2016 9:30 PM
To: Junping Du
Cc: common-...@hadoop.apache.org; hdfs-...@hadoop.apache.org; 
mapreduce-...@hadoop.apache.org; yarn-dev@hadoop.apache.org; Jason Lowe
Subject: Re: [Release thread] 2.6.5 release activities

Thanks Jason and Junping for the comments! I will update the spreadsheet for 
HADOOP-13362 and YARN-4794.

As for continuing 2.6.x releases, please see the discussion in the "[DISCUSS] 
2.6.x line releases" thread. Sean, Akira and Zhe all expressed interest in 
additional 2.6.x releases. I started this thread based off of that interest. I 
understand there is a burden to maintaining a large number of branches. I am 
not sure what the community's end-of-life policy is, but maybe we can issue a 
warning with the 2.6.5 release stating when we will stop maintaining the 
release line. This at least gives users some time to make migration plans to a 
newer version.

On Wed, Aug 10, 2016 at 9:36 AM, Junping Du 
> wrote:
Thanks Chris for bring up this discussion.
Before we going to detail discussion of releasing 2.6.5, I have a quick 
question here: do we think it is necessary to continue to release branch-2.6, 
like 2.6.5, etc after 2.7 is out for more than 1 year. Any reason to not 
suggest users to upgrade to 2.7.3 releases for latest fixes which is in 
releasing now?
My major concern on more release efforts on legacy branches is the same with my 
comments on other release plan before - it seems too many releases trains get 
planned at the same time window (2.6.x, 2.7.x, 2.8, 3.0-alpha, 3.1-beta, etc.). 
Not only user could get confusing on this, but also I suspect we don't have so 
many bandwidth in community to push forward so these releases in high quality 
during the same time window - just like Chris Douglas mentioned in another 
email thread on committer activity and bandwidth. IMO, may be it is better to 
focus on limited number of releases and move them faster?

BTW, I agree with Jason that HADOOP-13362 is not needed for branch-2.6 unless 
we backport container metrics related patches there.


Thanks,

Junping

From: Jason Lowe 
Sent: Wednesday, August 10, 2016 4:14 PM
To: Chris Trezzo; 
common-...@hadoop.apache.org; 
hdfs-...@hadoop.apache.org; 
mapreduce-...@hadoop.apache.org; 
yarn-dev@hadoop.apache.org
Subject: Re: [Release thread] 2.6.5 release activities

Thanks for organizing this, Chris!
I don't believe HADOOP-13362 is needed since it's related to ContainerMetrics.  
ContainerMetrics weren't added until 2.7 by YARN-2984.
YARN-4794 looks applicable to 2.6.  The change drops right in except it has 
JDK7-isms (multi-catch clause), so it needs a slight change.

Jason

  From: Chris Trezzo >
 To: "common-...@hadoop.apache.org" 
>; 
hdfs-...@hadoop.apache.org; 
"mapreduce-...@hadoop.apache.org" 
>; 
"yarn-dev@hadoop.apache.org" 
>
 Sent: Tuesday, August 9, 2016 7:32 PM
 Subject: [Release thread] 2.6.5 release activities

Based on the sentiment in the "[DISCUSS] 2.6.x line releases" thread, I
have moved forward with some of the initial effort in creating a 2.6.5
release. I am forking this thread so we have a dedicated 2.6.5 release
thread.

I have gone through the git logs and gathered a list of JIRAs that are in
branch-2.7 but are missing from branch-2.6. I limited the diff to issues
with a commit date after 1/26/2016. I did this because 2.6.4 was cut from
branch-2.6 around that date 

Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86

[Apache Jenkins Server]

For more details, see 
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/130/

[Aug 10, 2016 4:54:31 PM] (cnauroth) HADOOP-13476. CredentialProviderFactory 
fails at class loading from
[Aug 10, 2016 6:04:18 PM] (jlowe) YARN-5483. Optimize 
RMAppAttempt#pullJustFinishedContainers. Contributed
[Aug 10, 2016 6:07:42 PM] (shv) HDFS-10694. processReport() should print 
blockReportId in each log
[Aug 10, 2016 6:25:54 PM] (jlowe) YARN-5382. RM does not audit log kill request 
for active applications.
[Aug 10, 2016 7:05:19 PM] (naganarasimha_gr) YARN-5495. Remove import wildcard 
in CapacityScheduler. Contributed by
[Aug 10, 2016 10:14:38 PM] (xyao) Namenode should use loginUser(hdfs) to 
generateEncryptedKey. Contributed
[Aug 10, 2016 10:47:55 PM] (xyao) Revert "Namenode should use loginUser(hdfs) 
to generateEncryptedKey.
[Aug 10, 2016 10:49:36 PM] (xyao) HDFS-10643. Namenode should use 
loginUser(hdfs) to generateEncryptedKey.
[Aug 10, 2016 11:28:02 PM] (xiao) HADOOP-13461. NPE in 
KeyProvider.rollNewVersion. Contributed by Colm O
[Aug 11, 2016 2:23:29 AM] (rchiang) YARN-5137. Make DiskChecker pluggable in 
NodeManager. (Yufei Gu via
[Aug 12, 2016 3:15:05 AM] (kai.zheng) HDFS-10720. Fix intermittent test failure 
of
[Aug 11, 2016 5:17:35 AM] (weichiu) HDFS-8897. Balancer should handle 
fs.defaultFS trailing slash in HA.
[Aug 11, 2016 5:57:00 AM] (rohithsharmaks) YARN-2398. TestResourceTrackerOnHA 
crashes. Contributed by Ajith S.
[Aug 11, 2016 6:20:46 AM] (rohithsharmaks) YARN-5492. 
TestSubmitApplicationWithRMHA is failing sporadically during


[Error replacing 'FILE' - Workspace is not accessible]

-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org