[jira] [Created] (HADOOP-13490) create-release should not fail unless --asfrelease is used

[Allen Wittenauer (JIRA)]

Allen Wittenauer created HADOOP-13490:
-

 Summary: create-release should not fail unless --asfrelease is used
 Key: HADOOP-13490
 URL: https://issues.apache.org/jira/browse/HADOOP-13490
 Project: Hadoop Common
  Issue Type: Bug
  Components: build
Reporter: Allen Wittenauer


If someone is using create-release to build where the ASF isn't the target 
destination, there isn't much reason to fail out if RAT errors.



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

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

[jira] [Created] (HADOOP-13489) DistCp may incorrectly return success status when the underlying Job failed

[Ted Yu (JIRA)]

Ted Yu created HADOOP-13489:
---

 Summary: DistCp may incorrectly return success status when the 
underlying Job failed
 Key: HADOOP-13489
 URL: https://issues.apache.org/jira/browse/HADOOP-13489
 Project: Hadoop Common
  Issue Type: Bug
Reporter: Ted Yu


I was troubleshooting HBASE-14450 where at the end of BackupdistCp#execute(), 
distcp job was marked unsuccessful (BackupdistCp is a wrapper of DistCp).
Yet in IncrementalTableBackupProcedure#incrementalCopy(), the return value from 
copyService.copy() was 0.

Here is related code from DistCp:
{code}
try {
  execute();
} catch (InvalidInputException e) {
  LOG.error("Invalid input: ", e);
  return DistCpConstants.INVALID_ARGUMENT;
} catch (DuplicateFileException e) {
  LOG.error("Duplicate files in input path: ", e);
  return DistCpConstants.DUPLICATE_INPUT;
} catch (AclsNotSupportedException e) {
  LOG.error("ACLs not supported on at least one file system: ", e);
  return DistCpConstants.ACLS_NOT_SUPPORTED;
} catch (XAttrsNotSupportedException e) {
  LOG.error("XAttrs not supported on at least one file system: ", e);
  return DistCpConstants.XATTRS_NOT_SUPPORTED;
} catch (Exception e) {
  LOG.error("Exception encountered ", e);
  return DistCpConstants.UNKNOWN_ERROR;
}
return DistCpConstants.SUCCESS;
{code}
We don't check whether the Job returned by execute() was successful.
Even if the Job fails, DistCpConstants.SUCCESS is returned.



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

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

[jira] [Created] (HADOOP-13488) Have TryOnceThenFail implement ConnectionRetryPolicy

[Xiaobing Zhou (JIRA)]

Xiaobing Zhou created HADOOP-13488:
--

 Summary: Have TryOnceThenFail implement ConnectionRetryPolicy
 Key: HADOOP-13488
 URL: https://issues.apache.org/jira/browse/HADOOP-13488
 Project: Hadoop Common
  Issue Type: Sub-task
Reporter: Xiaobing Zhou
Assignee: Xiaobing Zhou






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

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-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: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

[jira] [Created] (HADOOP-13487) Hadoop KMS doesn't clean up old delegation tokens stored in Zookeeper

[Alex Ivanov (JIRA)]

Alex Ivanov created HADOOP-13487:


 Summary: Hadoop KMS doesn't clean up old delegation tokens stored 
in Zookeeper
 Key: HADOOP-13487
 URL: https://issues.apache.org/jira/browse/HADOOP-13487
 Project: Hadoop Common
  Issue Type: Bug
  Components: kms
Affects Versions: 2.6.0
Reporter: Alex Ivanov


Configuration:
CDH 5.5.1 (Hadoop 2.6+)
KMS configured to store delegation tokens in Zookeeper
DEBUG logging enabled in /etc/hadoop-kms/conf/kms-log4j.properties

Findings:
It seems to me delegation tokens never get cleaned up from Zookeeper past their 
renewal date. I can see in the logs that the removal thread is started with the 
expected interval:
{code}
2016-08-11 08:15:24,511 INFO  AbstractDelegationTokenSecretManager - Starting 
expired delegation token remover thread, tokenRemoverScanInterval=60 min(s)
{code}
However, I don't see any delegation token removals, indicated by the following 
log message:
org.apache.hadoop.security.token.delegation.ZKDelegationTokenSecretManager --> 
removeStoredToken(TokenIdent ident), line 769 [CDH]
{code}
if (LOG.isDebugEnabled()) {
  LOG.debug("Removing ZKDTSMDelegationToken_"
  + ident.getSequenceNumber());
}
{code}
Meanwhile, I see a lot of expired delegation tokens in Zookeeper that don't get 
cleaned up.



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

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

[jira] [Created] (HADOOP-13486) Method invocation in log can be replaced by variable because the variable's toString method contain more info

[Nemo Chen (JIRA)]

Nemo Chen created HADOOP-13486:
--

 Summary: Method invocation in log can be replaced by variable 
because the variable's toString method contain more info 
 Key: HADOOP-13486
 URL: https://issues.apache.org/jira/browse/HADOOP-13486
 Project: Hadoop Common
  Issue Type: Bug
Affects Versions: 2.7.2
Reporter: Nemo Chen


Similar to the fix in HADOOP-6419, in file:

hadoop-rel-release-2.7.2/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/Server.java

{code}
Connection c = (Connection)key.attachment();
...
LOG.info(Thread.currentThread().getName() + ": readAndProcess from client " + 
c.getHostAddress() + " threw exception [" + e + "]", (e instanceof 
WrappedRpcServerException) ? null : e);
...
{code}

in class Connection, the toString method contains both getHostAddress() and 
remotePort
{code}
public String toString() {
  return getHostAddress() + ":" + remotePort; 
}
{code}

Therefore the c.getHostAddress() should be replaced by c for simplicity and 
information wise.



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

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-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-dev@hadoop.apache.org; hdfs-...@hadoop.apache.org; 
mapreduce-...@hadoop.apache.org; yarn-...@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: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

[jira] [Created] (HADOOP-13485) Log refactoring: method invocation should be replaced by variable in hadoop tools

[Nemo Chen (JIRA)]

Nemo Chen created HADOOP-13485:
--

 Summary: Log refactoring: method invocation should be replaced by 
variable in hadoop tools
 Key: HADOOP-13485
 URL: https://issues.apache.org/jira/browse/HADOOP-13485
 Project: Hadoop Common
  Issue Type: Bug
  Components: tools
Affects Versions: 2.7.2
Reporter: Nemo Chen


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

hadoop-rel-release-2.7.2/hadoop-tools/hadoop-azure/src/main/java/org/apache/hadoop/fs/azure/NativeAzureFileSystem.java
{code:borderStyle=solid}
this.blockSize = conf.getLong(AZURE_BLOCK_SIZE_PROPERTY_NAME,
MAX_AZURE_BLOCK_SIZE);
if (LOG.isDebugEnabled()) {
LOG.debug("NativeAzureFileSystem. Initializing.");
LOG.debug("  blockSize  = "
  + conf.getLong(AZURE_BLOCK_SIZE_PROPERTY_NAME, MAX_AZURE_BLOCK_SIZE));
}
{code}
For simplicity and readability, the 
{{conf.getLong(AZURE_BLOCK_SIZE_PROPERTY_NAME, MAX_AZURE_BLOCK_SIZE))}} should 
be changed to {{this.blockSize}}.



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

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

[jira] [Created] (HADOOP-13484) Log refactoring: method invocation should be replaced by variable

[Nemo Chen (JIRA)]

Nemo Chen created HADOOP-13484:
--

 Summary: Log refactoring: method invocation should be replaced by 
variable
 Key: HADOOP-13484
 URL: https://issues.apache.org/jira/browse/HADOOP-13484
 Project: Hadoop Common
  Issue Type: Bug
  Components: metrics
Affects Versions: 2.7.2
Reporter: Nemo Chen


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

hadoop-rel-release-2.7.2/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/metrics2/lib/MutableRates.java

In code block:
{code:borderStyle=solid}
String name = method.getName();
LOG.debug(name);
try { registry.newRate(name, name, false, true); }
catch (Exception e) {
LOG.error("Error creating rate metrics for "+ method.getName(), e);
}
{code}
method.getName() is better to be replaced by variable name.




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

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

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: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-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-dev@hadoop.apache.org; hdfs-...@hadoop.apache.org; 
mapreduce-...@hadoop.apache.org; yarn-...@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-dev@hadoop.apache.org; 
hdfs-...@hadoop.apache.org; 
mapreduce-...@hadoop.apache.org; 
yarn-...@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-dev@hadoop.apache.org" 
>; 
hdfs-...@hadoop.apache.org; 
"mapreduce-...@hadoop.apache.org" 
>; 
"yarn-...@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: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org