Jenkins build is back to normal : Hadoop-Common-trunk #2200

2016-01-08 Thread Apache Jenkins Server 
See

Build failed in Jenkins: Hadoop-common-trunk-Java8 #902

2016-01-08 Thread Apache Jenkins Server 
See 

Changes:

[cnauroth] HADOOP-12678. Handle empty rename pending metadata file during atomic

--
[...truncated 3899 lines...]
[INFO] Compiling 2 source files to 

[INFO] 
[INFO] --- maven-surefire-plugin:2.17:test (default-test) @ hadoop-minikdc ---
[INFO] Surefire report directory: 


---
 T E S T S
---

---
 T E S T S
---
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.minikdc.TestChangeOrgNameAndDomain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 9.91 sec - in 
org.apache.hadoop.minikdc.TestChangeOrgNameAndDomain
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.minikdc.TestMiniKdc
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 8.158 sec - in 
org.apache.hadoop.minikdc.TestMiniKdc

Results :

Tests run: 6, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] --- maven-jar-plugin:2.5:jar (default-jar) @ hadoop-minikdc ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-source-plugin:2.3:jar-no-fork (hadoop-java-sources) @ 
hadoop-minikdc ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-source-plugin:2.3:test-jar-no-fork (hadoop-java-sources) @ 
hadoop-minikdc ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (dist-enforce) @ hadoop-minikdc 
---
[INFO] 
[INFO] --- maven-site-plugin:3.4:attach-descriptor (attach-descriptor) @ 
hadoop-minikdc ---
[INFO] 
[INFO] --- maven-javadoc-plugin:2.8.1:jar (module-javadocs) @ hadoop-minikdc ---
[INFO] 
Loading source files for package org.apache.hadoop.minikdc...
Constructing Javadoc information...
Standard Doclet version 1.8.0
Building tree for all the packages and classes...
Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Building index for all the packages and classes...
Generating 

Generating 

Generating 

Building index for all classes...
Generating 

Generating

Build failed in Jenkins: Hadoop-Common-trunk #2199

2016-01-08 Thread Apache Jenkins Server 
See 

Changes:

[lei] HDFS-9493. Test o.a.h.hdfs.server.namenode.TestMetaSave fails in trunk. 

[jianhe] YARN-4479. Change CS LeafQueue pendingOrderingPolicy to hornor 
recovered

--
[...truncated 8571 lines...]
  [javadoc] Loading source files for package org.apache.hadoop.metrics...
  [javadoc] Loading source files for package 
org.apache.hadoop.metrics.ganglia...
  [javadoc] Loading source files for package org.apache.hadoop.metrics.jvm...
  [javadoc] Loading source files for package org.apache.hadoop.metrics.spi...
  [javadoc] Loading source files for package org.apache.hadoop.metrics.util...
  [javadoc] Loading source files for package org.apache.hadoop.metrics2...
  [javadoc] Loading source files for package 
org.apache.hadoop.metrics2.annotation...
  [javadoc] Loading source files for package 
org.apache.hadoop.metrics2.filter...
  [javadoc] Loading source files for package org.apache.hadoop.metrics2.impl...
  [javadoc] Loading source files for package org.apache.hadoop.metrics2.lib...
  [javadoc] Loading source files for package org.apache.hadoop.metrics2.sink...
  [javadoc] Loading source files for package 
org.apache.hadoop.metrics2.sink.ganglia...
  [javadoc] Loading source files for package 
org.apache.hadoop.metrics2.source...
  [javadoc] Loading source files for package org.apache.hadoop.metrics2.util...
  [javadoc] Loading source files for package org.apache.hadoop.net...
  [javadoc] Loading source files for package org.apache.hadoop.net.unix...
  [javadoc] Loading source files for package org.apache.hadoop.security...
  [javadoc] Loading source files for package org.apache.hadoop.security.alias...
  [javadoc] Loading source files for package 
org.apache.hadoop.security.authorize...
  [javadoc] Loading source files for package org.apache.hadoop.security.http...
  [javadoc] Loading source files for package 
org.apache.hadoop.security.protocolPB...
  [javadoc] Loading source files for package org.apache.hadoop.security.ssl...
  [javadoc] Loading source files for package org.apache.hadoop.security.token...
  [javadoc] Loading source files for package 
org.apache.hadoop.security.token.delegation...
  [javadoc] Loading source files for package 
org.apache.hadoop.security.token.delegation.web...
  [javadoc] Loading source files for package org.apache.hadoop.service...
  [javadoc] Loading source files for package org.apache.hadoop.tools...
  [javadoc] Loading source files for package 
org.apache.hadoop.tools.protocolPB...
  [javadoc] Loading source files for package org.apache.hadoop.tracing...
  [javadoc] Loading source files for package org.apache.hadoop.util...
  [javadoc] Loading source files for package org.apache.hadoop.util.bloom...
  [javadoc] Loading source files for package org.apache.hadoop.util.curator...
  [javadoc] Loading source files for package org.apache.hadoop.util.hash...
  [javadoc] Constructing Javadoc information...
  [javadoc] 
:46:
 warning: Unsafe is internal proprietary API and may be removed in a future 
release
  [javadoc] import sun.misc.Unsafe;
  [javadoc]^
  [javadoc] 
:25:
 warning: Unsafe is internal proprietary API and may be removed in a future 
release
  [javadoc] import sun.misc.Unsafe;
  [javadoc]^
  [javadoc] 
:54:
 warning: ResolverConfiguration is internal proprietary API and may be removed 
in a future release
  [javadoc] import sun.net.dns.ResolverConfiguration;
  [javadoc]   ^
  [javadoc] 
:55:
 warning: IPAddressUtil is internal proprietary API and may be removed in a 
future release
  [javadoc] import sun.net.util.IPAddressUtil;
  [javadoc]^
  [javadoc] 
:21:
 warning: Signal is internal proprietary API and may be removed in a future 
release
  [javadoc] import sun.misc.Signal;
  [javadoc]^
  [javadoc] 
:22:
 warning: SignalHandler is internal proprietary API and may be removed in a 
future release
  [javadoc] import sun.misc.SignalHandler;
  [javadoc]^
  [javadoc]

Jenkins build is back to normal : Hadoop-common-trunk-Java8 #900

2016-01-08 Thread Apache Jenkins Server 
See

Re: Google Cloud Storage connector into Hadoop

2016-01-08 Thread jay vyas 
See also the HCFS wiki page https://wiki.apache.org/hadoop/HCFS/Progress
which attempts to explain this stuff for the community, maybe it needs some
updates as well, i haven't looked in a while as ive moved onto working on
other products nowadays




On Tue, Dec 8, 2015 at 12:50 PM, Steve Loughran 
wrote:

>
> 1. do what chris says: go for the abstract contract tests. They'll find
> the troublespots in your code, like the way seek(-1) appears to have
> entertaining results, what happens on operations to closed files, etc, and
> help identify where the semantics of your FS varies from HDFS.
>
> 2. You will need to stay with the versions of artifacts in the Hadoop
> codebase. Troublespots there are protobuf (frozen @ 2.5) and guava
> (shipping with 11.02, code must run against 18.x + if someone upgrades). If
> this is problematic you may want discuss the versioning issues there with
> your colleagues; see https://issues.apache.org/jira/browse/HADOOP-10101
> for the details.
>
> 3. the object stores get undertested: jenkins doesn't touch them for patch
> review or nightly runs —you can't give jenkins the right credentials.
> Setting up your own jenkins server to build the Hadoop versions and flag
> problems would be a great contribution here. Also: help with the release
> testing; if someone has a patch for the hadoop-gcs module, review and test
> that too would be great; stops these patches being neglected.
>
> 4. We could do with some more scale tests of the object stores, to test
> creating many thousands of small files, etc. Contributions welcome
>
> 5. We could do with a lot more downstream testing of things like hive &
> spark IO on object stores, especially via ORC and Parquet. Helping to write
> those tests would stop regressions in the stack, and help tune Hadoop for
> your FS.
>
> 6. Finally: don't be afraid to get involved with the rest of the codebase.
> It can only get better.
>
>
> > On 8 Dec 2015, at 00:20, James Malone 
> wrote:
> >
> > Haohui & Chris,
> >
> > Sounds great, thank you very much! We'll cut a JIRA once we get
> everything
> > lined up.
> >
> > Best,
> >
> > James
> >
> > On Mon, Dec 7, 2015 at 3:54 PM, Chris Nauroth 
> > wrote:
> >
> >> Hi James,
> >>
> >> This sounds great!  Thank you for considering contributing the code.
> >>
> >> Just seconding what Haohui said, there is existing precedent for
> >> alternative implementations of the Hadoop FileSystem in our codebase.
> We
> >> currently have similar plugins for S3 [1], Azure [2] and OpenStack Swift
> >> [3].  Additionally, we have a suite of FileSystem contract tests [4].
> >> These tests are designed to help developers of alternative file systems
> >> assess how closely they match the semantics expected by Hadoop ecosystem
> >> components.
> >>
> >> Many Hadoop users are accustomed to using HDFS instead of these
> >> alternative file systems, so none of the alternatives are on the default
> >> Hadoop classpath immediately after deployment.  Instead, the code for
> each
> >> one is in a separate module under the "hadoop-tools" directory in the
> >> source tree.  Users who need to use the alternative file systems take
> >> extra steps post-deployment to add them to the classpath where
> necessary.
> >> This achieves the dependency isolation needed.  For example, users who
> >> never use the Azure plugin won't accidentally pick up a transitive
> >> dependency on the Azure SDK jar.
> >>
> >> I recommend taking a quick glance through the existing modules for S3,
> >> Azure and OpenStack.  We'll likely ask that a new FileSystem
> >> implementation follow the same patterns if feasible for consistency.
> This
> >> would include things like using the contract tests, having a provision
> to
> >> execute tests both offline/mocked and live/integrated with the real
> >> service and providing a documentation page that explains configuration
> for
> >> end users.
> >>
> >> For now, please feel free to file a HADOOP JIRA with your proposal.  We
> >> can work out the details of all of this in discussion on that JIRA.
> >>
> >> Something else to follow up on will be licensing concerns.  I see the
> >> project already uses the Apache license, but it appears to be an
> existing
> >> body of code initially developed at Google.  That might require a
> Software
> >> Grant Agreement [5].  Again, this is something that can be hashed out in
> >> discussion on the JIRA after you create it.
> >>
> >> [1]
> >>
> http://hadoop.apache.org/docs/r2.7.1/hadoop-aws/tools/hadoop-aws/index.html
> >> [2] http://hadoop.apache.org/docs/r2.7.1/hadoop-azure/index.html
> >> [3] http://hadoop.apache.org/docs/r2.7.1/hadoop-openstack/index.html
> >> [4]
> >>
> http://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-common/file
> >> system/testing.html
> >> [5] http://www.apache.org/licenses/
> >>
> >> --Chris Nauroth
> >>
> >>
> >>
> >>
> >> On 12/7/15, 3:10 PM, "Haohui Mai"  wrote:
> >>
> >>> Hi,
> >>>
> >>> Thanks for reaching out. It would be great to see thi

[jira] [Created] (HADOOP-12699) TestKMS#testKMSProvider intermittently fails during 'test rollover draining'

2016-01-08 Thread Xiao Chen (JIRA) 
Xiao Chen created HADOOP-12699:
--

 Summary: TestKMS#testKMSProvider intermittently fails during 'test 
rollover draining'
 Key: HADOOP-12699
 URL: https://issues.apache.org/jira/browse/HADOOP-12699
 Project: Hadoop Common
  Issue Type: Bug
Reporter: Xiao Chen
Assignee: Xiao Chen


I've seen several failures of testKMSProvider, all failed in the following 
snippet:
{code}
// test rollover draining
KeyProviderCryptoExtension kpce = KeyProviderCryptoExtension.
createKeyProviderCryptoExtension(kp);
.

EncryptedKeyVersion ekv1 = kpce.generateEncryptedKey("k6");
kpce.rollNewVersion("k6");
EncryptedKeyVersion ekv2 = kpce.generateEncryptedKey("k6");
Assert.assertNotEquals(ekv1.getEncryptionKeyVersionName(),
ekv2.getEncryptionKeyVersionName());
{code}
with error message
{quote}Values should be different. Actual: k6@0{quote}



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

Re: [VOTE] Release Apache Hadoop 2.7.2 RC1

2016-01-08 Thread Sangjin Lee 
I agree that it would be a good practice to maintain parity between 2.6.x
and 2.7.x as much as possible. Departure from it should be more of an
exception than the norm.

That said, it is also true that we're not exactly following the semantic
versioning the moment we started to maintain multiple simultaneous release
branches. In semantic versioning, the timing of the release doesn't really
matter. If we were following semantic versioning, all releases in 2.6.x
would be considered "earlier versions" than 2.7.x regardless of their
release time. Obviously we cannot ensure no regression in that situation.

FWIW.


On Fri, Jan 8, 2016 at 11:43 AM, Andrew Wang 
wrote:

> I like monotonic releases since it's simple for users to understand. Is it
> difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
> don't follow why special casing some class of fixes is desirable.
>
> Also for maintenance releases, aren't all included fixes supposed to be for
> serious bugs? Minor JIRAs can wait for the next minor release. If there are
> strong reasons to include a minor JIRA in a maintenance release, then maybe
> it's not really a minor JIRA.
>
> Best,
> Andrew
>
> On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA 
> wrote:
>
> > The general rule sounds good to me.
> >
> > > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> > get out after 2.x.y release date"
> >
> > +1
> >
> > > I would prefer this rule only applies on critical/blocker fixes, but
> not
> > applies on minor/trivial issues.
> >
> > +1
> >
> > Thanks,
> > Akira
> >
> >
> > On 12/29/15 23:50, Junping Du wrote:
> >
> >> I am +1 with pulling all of these tickets into 2.7.2.
> >>
> >> - For “any fix in 2.6.3 to be there in all releases that get out after
> >> 2.6.3 release date”
> >>
> >> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
> >> in all 2.b.c releases (while b>=x) that get out after 2.x.y release
> date"?
> >> I am generally fine with this, but just feel it sounds to set too strong
> >> restrictions among branches. Some fixes could be trivial (test case fix,
> >> etc.) enough to deserve more flexibility.​ I would prefer this rule only
> >> applies on critical/blocker fixes, but not applies on minor/trivial
> issues.
> >>
> >> Just 2 cents.
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Junping
> >>
> >>
> >> 
> >> From: Vinod Kumar Vavilapalli 
> >> Sent: Thursday, December 24, 2015 12:47 AM
> >> To: Junping Du
> >> Cc: mapreduce-...@hadoop.apache.org; yarn-...@hadoop.apache.org;
> >> common-dev@hadoop.apache.org; hdfs-...@hadoop.apache.org
> >> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
> >>
> >> I retract my -1. I think we will need to discuss this a bit more.
> >>
> >> Beyond those two tickets, there are a bunch more (totaling to 16) that
> >> are in 2.6.3 but *not* in 2.7.2. See this:
> >>
> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
> >> <
> >>
> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
> >> >
> >>
> >> Two options here, depending on the importance of ‘causality' between
> >> 2.6.x and 2.7.x lines.
> >>   - Ship 2.7.2 as we voted on here
> >>   - Pull these 16 tickets into 2.7.2 and roll a new RC
> >>
> >> What do people think? Do folks expect “any fix in 2.6.3 to be there in
> >> all releases that get out after 2.6.3 release date (December 16th)”?
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <
> vino...@apache.org
> >> > wrote:
> >>
> >> Sigh. Missed this.
> >>
> >> To retain causality ("any fix in 2.6.3 will be there in all releases
> that
> >> got out after 2.6.3”), I’ll get these patches in.
> >>
> >> Reverting my +1, and casting -1 for the RC myself.
> >>
> >> Will spin a new RC, this voting thread is marked dead.
> >>
> >> Thanks
> >> +Vinod
> >>
> >> On Dec 22, 2015, at 8:24 AM, Junping Du  >> j...@hortonworks.com>> wrote:
> >>
> >> However, when I look at our commit log and CHANGES.txt, I found
> something
> >> we are missing:
> >> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1
> tag.
> >> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
> >>
> >>
> >>
> >
>

Build failed in Jenkins: Hadoop-Common-trunk #2198

2016-01-08 Thread Apache Jenkins Server 
See 

Changes:

[zhz] HDFS-9626. TestBlockReplacement#testBlockReplacement fails occasionally.

--
[...truncated 5428 lines...]
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.951 sec - in 
org.apache.hadoop.metrics2.source.TestJvmMetrics
Running org.apache.hadoop.metrics2.filter.TestPatternFilter
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.599 sec - in 
org.apache.hadoop.metrics2.filter.TestPatternFilter
Running org.apache.hadoop.conf.TestConfigurationSubclass
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.534 sec - in 
org.apache.hadoop.conf.TestConfigurationSubclass
Running org.apache.hadoop.conf.TestGetInstances
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.429 sec - in 
org.apache.hadoop.conf.TestGetInstances
Running org.apache.hadoop.conf.TestConfigurationDeprecation
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.285 sec - in 
org.apache.hadoop.conf.TestConfigurationDeprecation
Running org.apache.hadoop.conf.TestDeprecatedKeys
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.694 sec - in 
org.apache.hadoop.conf.TestDeprecatedKeys
Running org.apache.hadoop.conf.TestConfiguration
Tests run: 62, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.571 sec - in 
org.apache.hadoop.conf.TestConfiguration
Running org.apache.hadoop.conf.TestReconfiguration
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.563 sec - in 
org.apache.hadoop.conf.TestReconfiguration
Running org.apache.hadoop.conf.TestConfServlet
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.748 sec - in 
org.apache.hadoop.conf.TestConfServlet
Running org.apache.hadoop.test.TestJUnitSetup
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.181 sec - in 
org.apache.hadoop.test.TestJUnitSetup
Running org.apache.hadoop.test.TestMultithreadedTestUtil
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.209 sec - in 
org.apache.hadoop.test.TestMultithreadedTestUtil
Running org.apache.hadoop.test.TestGenericTestUtils
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.206 sec - in 
org.apache.hadoop.test.TestGenericTestUtils
Running org.apache.hadoop.test.TestTimedOutTestsListener
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.276 sec - in 
org.apache.hadoop.test.TestTimedOutTestsListener
Running org.apache.hadoop.metrics.TestMetricsServlet
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.102 sec - in 
org.apache.hadoop.metrics.TestMetricsServlet
Running org.apache.hadoop.metrics.spi.TestOutputRecord
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.067 sec - in 
org.apache.hadoop.metrics.spi.TestOutputRecord
Running org.apache.hadoop.metrics.ganglia.TestGangliaContext
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.219 sec - in 
org.apache.hadoop.metrics.ganglia.TestGangliaContext
Running org.apache.hadoop.net.TestNetUtils
Tests run: 40, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.797 sec - in 
org.apache.hadoop.net.TestNetUtils
Running org.apache.hadoop.net.TestDNS
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.401 sec - in 
org.apache.hadoop.net.TestDNS
Running org.apache.hadoop.net.TestSocketIOWithTimeout
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.451 sec - in 
org.apache.hadoop.net.TestSocketIOWithTimeout
Running org.apache.hadoop.net.TestNetworkTopologyWithNodeGroup
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.261 sec - in 
org.apache.hadoop.net.TestNetworkTopologyWithNodeGroup
Running org.apache.hadoop.net.TestClusterTopology
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.295 sec - in 
org.apache.hadoop.net.TestClusterTopology
Running org.apache.hadoop.net.TestScriptBasedMappingWithDependency
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.669 sec - in 
org.apache.hadoop.net.TestScriptBasedMappingWithDependency
Running org.apache.hadoop.net.TestTableMapping
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.755 sec - in 
org.apache.hadoop.net.TestTableMapping
Running org.apache.hadoop.net.TestScriptBasedMapping
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.672 sec - in 
org.apache.hadoop.net.TestScriptBasedMapping
Running org.apache.hadoop.net.unix.TestDomainSocketWatcher
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.761 sec - in 
org.apache.hadoop.net.unix.TestDomainSocketWatcher
Running org.apache.hadoop.net.unix.TestDomainSocket
Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.981 sec - in 
org.apache.hadoop.net.unix.TestDomainSocket
Running org.apache.hadoop.net.TestSwitchMapping
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.463 sec - in 
org.apache.hadoop.net.TestSwitchMapping
Running

[GitHub] hadoop pull request: YARN-679 service launcher

2016-01-08 Thread steveloughran 
GitHub user steveloughran opened a pull request:

https://github.com/apache/hadoop/pull/68

YARN-679 service launcher

Pull-request version of YARN-679; initially the 005 patch plus corrections 
of javadocs and checkstyles

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/steveloughran/hadoop stevel/YARN-679-launcher

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/hadoop/pull/68.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #68


commit 8190fcbea75d203a43052339736ea2a412d44f16
Author: Steve Loughran 
Date:   2014-06-03T17:09:26Z

YARN-679: launcher code move

commit 5216a290371eb9050bf1fc98cd82aeea05f2f9d5
Author: Steve Loughran 
Date:   2014-06-03T18:43:41Z

YARN-679 service launcher adapting to changes in ExitUtil; passng params 
down as a list


commit a8ea0b26cb101dbfc47bb8349bfa3510d0701efe
Author: Steve Loughran 
Date:   2014-06-04T09:46:45Z

YARN-679 add javadocs & better launching for service-launcher

commit dcb4599ca9ed1feadff2d0149819640740405201
Author: Steve Loughran 
Date:   2014-06-04T10:54:44Z

YARN-679 move IRQ escalation into its own class for cleanliness and 
testability; lots of javadocs

commit bdd41f632deeb60a0b309e891755630d93956280
Author: Steve Loughran 
Date:   2014-06-04T13:19:53Z

YARN-679 initial TestInterruptHandling test

commit ff422b3dd70a9a39d7668b063811acee285fcbba
Author: Steve Loughran 
Date:   2014-06-04T14:26:33Z

YARN-679 TestInterruptHandling

commit 1d35197f8a8d80d3ca9aa4691b7f086686fcb454
Author: Steve Loughran 
Date:   2014-06-04T14:40:13Z

YARN-679 TestInterruptHandling final test -that blocking service stops 
don't stop shutdown from kicking in


commit ddbdfae3f7e2ce79f3c0138bc5c855bde8094c2f
Author: Steve Loughran 
Date:   2014-06-04T15:41:19Z

YARN-679: service exception handling improvements during creation, 
sprintf-formatted exception creation

commit db0a2ef4e8a46bfab6db4ec7a89cde70779432c8
Author: Steve Loughran 
Date:   2014-06-04T15:56:11Z

YARN-679 service instantiation failures

commit 2a95da1a320811c381b93c14125d56e2d21798c1
Author: Steve Loughran 
Date:   2014-06-04T17:41:54Z

YARN-679 lots more on exception handling and error code propagation, 
including making ServiceStateException have an exit code and propagate any 
inner one

commit 6fc00fa46e47d1ae6039d2e6d16b8bfb61c87ea1
Author: Steve Loughran 
Date:   2014-06-04T19:12:13Z

YARN-679 move test services into their own package; test for stop in 
runnable

commit 4dfed85a0a86440784583c41d2249d6c1106889d
Author: Steve Loughran 
Date:   2014-06-04T20:00:20Z

YARN-679 conf arg passdown validated

commit 6c12bb43a1d4554e7e196db7f9994562bd899fee
Author: Steve Loughran 
Date:   2014-06-05T10:03:34Z

YARN-679 test for service launch

commit 803250fb6810e7bd2373c53c9c07d9548c9eb71d
Author: Steve Loughran 
Date:   2014-06-05T12:46:26Z

YARN-679 test for bindArgs operations

commit f21f0fe6bdd8b1815080bdead225572c93430a24
Author: Steve Loughran 
Date:   2014-06-05T13:05:30Z

YARN-679 add AbstractLaunchedService base class for launched services, 
tests to verify that a subclass of this rejects arguments -but doesn't reject 
--conf args as they are stripped

commit a7056381a61fac239f71c7ecb8c40b74c4330864
Author: Steve Loughran 
Date:   2014-06-05T13:24:24Z

YARN-679 exception throwing/catching in execute

commit 24b74787dc52ca41dd6fde9db6c1dddb471ba1b8
Author: Steve Loughran 
Date:   2014-06-05T14:13:35Z

YARN-679 verify that constructor inits are handled

commit 554e317a0f2ef6ea353887e0cc501e0d27eb9a27
Author: Steve Loughran 
Date:   2014-06-05T14:28:14Z

services that only have a (String) constructor are handled by giving them 
their classname as a name

commit 49e457785752c1c27137ce1bb448b00f565cff20
Author: Steve Loughran 
Date:   2014-06-05T14:31:43Z

YARN-679 optimise imports

commit 62984ff26819965e86eb8727d1c5d8b73cd7fce9
Author: Steve Loughran 
Date:   2014-06-05T16:45:29Z

YARN-679 inner Launching logic with assertions and checks that Throwables 
get picked up and wrapped

commit ad8b79023536ebb1975613abbeb592f8826c06b2
Author: Steve Loughran 
Date:   2014-06-05T18:48:21Z

YARN-679 executed services close unless execute=false on launch, at which 
point they don't even get executed

commit f73e856e8c2cf4d5c3fa2c9b383e110917f79700
Author: Steve Loughran 
Date:   2014-06-05T18:49:00Z

YARN-679 rm unused override

commit 97a2af7be6a93af480a142eba93a130d98e2bd24
Author: Steve Loughran 
Date:   2014-06-05T19:09:49Z

YARN-679 give all tests a TestService to identify their role and aid bulk 
mvn test runs

commit 7276e349a51fb7593fa4edcd8a917bf52eea36a7
Author: Steve Loughran 
Date:   2014-06-05T19:28:47Z

YARN-679 rename LaunchedService interface LaunchableService

commit

Re: [VOTE] Release Apache Hadoop 2.7.2 RC1

2016-01-08 Thread Andrew Wang 
I like monotonic releases since it's simple for users to understand. Is it
difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
don't follow why special casing some class of fixes is desirable.

Also for maintenance releases, aren't all included fixes supposed to be for
serious bugs? Minor JIRAs can wait for the next minor release. If there are
strong reasons to include a minor JIRA in a maintenance release, then maybe
it's not really a minor JIRA.

Best,
Andrew

On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA 
wrote:

> The general rule sounds good to me.
>
> > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that
> get out after 2.x.y release date"
>
> +1
>
> > I would prefer this rule only applies on critical/blocker fixes, but not
> applies on minor/trivial issues.
>
> +1
>
> Thanks,
> Akira
>
>
> On 12/29/15 23:50, Junping Du wrote:
>
>> I am +1 with pulling all of these tickets into 2.7.2.
>>
>> - For “any fix in 2.6.3 to be there in all releases that get out after
>> 2.6.3 release date”
>>
>> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
>> in all 2.b.c releases (while b>=x) that get out after 2.x.y release date"?
>> I am generally fine with this, but just feel it sounds to set too strong
>> restrictions among branches. Some fixes could be trivial (test case fix,
>> etc.) enough to deserve more flexibility.​ I would prefer this rule only
>> applies on critical/blocker fixes, but not applies on minor/trivial issues.
>>
>> Just 2 cents.
>>
>>
>> Thanks,
>>
>>
>> Junping
>>
>>
>> 
>> From: Vinod Kumar Vavilapalli 
>> Sent: Thursday, December 24, 2015 12:47 AM
>> To: Junping Du
>> Cc: mapreduce-...@hadoop.apache.org; yarn-...@hadoop.apache.org;
>> common-dev@hadoop.apache.org; hdfs-...@hadoop.apache.org
>> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
>>
>> I retract my -1. I think we will need to discuss this a bit more.
>>
>> Beyond those two tickets, there are a bunch more (totaling to 16) that
>> are in 2.6.3 but *not* in 2.7.2. See this:
>> https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
>> <
>> https://issues.apache.org/jira/issues/?jql=key%20in%20(HADOOP-12526,HADOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVersion%20!=%202.7.0
>> >
>>
>> Two options here, depending on the importance of ‘causality' between
>> 2.6.x and 2.7.x lines.
>>   - Ship 2.7.2 as we voted on here
>>   - Pull these 16 tickets into 2.7.2 and roll a new RC
>>
>> What do people think? Do folks expect “any fix in 2.6.3 to be there in
>> all releases that get out after 2.6.3 release date (December 16th)”?
>>
>> Thanks
>> +Vinod
>>
>> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli > > wrote:
>>
>> Sigh. Missed this.
>>
>> To retain causality ("any fix in 2.6.3 will be there in all releases that
>> got out after 2.6.3”), I’ll get these patches in.
>>
>> Reverting my +1, and casting -1 for the RC myself.
>>
>> Will spin a new RC, this voting thread is marked dead.
>>
>> Thanks
>> +Vinod
>>
>> On Dec 22, 2015, at 8:24 AM, Junping Du > j...@hortonworks.com>> wrote:
>>
>> However, when I look at our commit log and CHANGES.txt, I found something
>> we are missing:
>> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1 tag.
>> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
>>
>>
>>
>

[GitHub] hadoop pull request: YARN-4567 javadoc failing on java 8

2016-01-08 Thread steveloughran 
GitHub user steveloughran opened a pull request:

https://github.com/apache/hadoop/pull/67

YARN-4567 javadoc failing on java 8



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/steveloughran/hadoop 
stevel/patches/YARN-4567-java8

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/hadoop/pull/67.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #67


commit eda776bdb3153f4821d4b7e05554ff8d1a0f0ab8
Author: Steve Loughran 
Date:   2016-01-08T19:42:37Z

YARN-4567 javadoc failing on java 8




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Build failed in Jenkins: Hadoop-common-trunk-Java8 #899

2016-01-08 Thread Apache Jenkins Server 
See 

Changes:

[kihwal] HDFS-9574. Reduce client failures during datanode restart. Contributed

--
[...truncated 5816 lines...]
Running org.apache.hadoop.util.TestVersionUtil
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.196 sec - in 
org.apache.hadoop.util.TestVersionUtil
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestProtoUtil
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.282 sec - in 
org.apache.hadoop.util.TestProtoUtil
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestLightWeightGSet
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.192 sec - in 
org.apache.hadoop.util.TestLightWeightGSet
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestGSet
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.002 sec - in 
org.apache.hadoop.util.TestGSet
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestStringInterner
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.134 sec - in 
org.apache.hadoop.util.TestStringInterner
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestZKUtil
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.136 sec - in 
org.apache.hadoop.util.TestZKUtil
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestStringUtils
Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.314 sec - in 
org.apache.hadoop.util.TestStringUtils
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestFindClass
Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.721 sec - in 
org.apache.hadoop.util.TestFindClass
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestGenericOptionsParser
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.974 sec - in 
org.apache.hadoop.util.TestGenericOptionsParser
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestRunJar
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.446 sec - in 
org.apache.hadoop.util.TestRunJar
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestSysInfoLinux
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.261 sec - in 
org.apache.hadoop.util.TestSysInfoLinux
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestDirectBufferPool
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.176 sec - in 
org.apache.hadoop.util.TestDirectBufferPool
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestFileBasedIPList
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.229 sec - in 
org.apache.hadoop.util.TestFileBasedIPList
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestIndexedSort
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.82 sec - in 
org.apache.hadoop.util.TestIndexedSort
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestIdentityHashStore
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.203 sec - in 
org.apache.hadoop.util.TestIdentityHashStore
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestMachineList
Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.976 sec - in 
org.apache.hadoop.util.TestMachineList
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.TestWinUtils
Tests run: 11, Failures: 0, Errors: 0, Skipped: 11, Time elapsed: 0.266 sec - 
in org.apache.hadoop.util.TestWinUtils
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=768m; 
support was removed in 8.0
Running org.apache.hadoop.util.hash.TestHash
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.392 sec - in 
org.apach

[GitHub] hadoop pull request: YARN-2571 RM to support YARN registry

2016-01-08 Thread steveloughran 
GitHub user steveloughran opened a pull request:

https://github.com/apache/hadoop/pull/66

YARN-2571 RM to support YARN registry



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/steveloughran/hadoop 
YARN-913/YARN-2571-RM-on-trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/hadoop/pull/66.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #66


commit 25a56da6037bb50d3ce5bbcc3001914e51ea2457
Author: Steve Loughran 
Date:   2015-11-11T20:20:23Z

YARN-2571 RM setup of registry, reapplied to trunk




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] hadoop pull request: YARN-1564 add some basic workflow YARN servic...

2016-01-08 Thread steveloughran 
GitHub user steveloughran opened a pull request:

https://github.com/apache/hadoop/pull/65

YARN-1564 add some basic workflow YARN services

YARN-1564 add some basic workflow YARN services

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/steveloughran/hadoop 
stevel/YARN-1564-workflow-services

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/hadoop/pull/65.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #65


commit d9f0172abfd904bad80e9e245fc792560a874834
Author: Steve Loughran 
Date:   2014-06-03T15:46:54Z

YARN-1564 - Patch-001

commit b0101e65cb1e6ed4171212f78c6d75ac855ccb5c
Author: Steve Loughran 
Date:   2014-12-04T15:30:52Z

YARN-1564 sync up with slider tweaks, primarily the disabling of tests on 
windows which only work if the relevant external commands are on the path

commit 8f262578c67edc4e6cbdef3e9bc338dabcd2ecf4
Author: Steve Loughran 
Date:   2015-05-05T12:56:14Z

YARN-1564 review and update workflow services, including making original 
CompositeService a ServiceParent; moving to Java 7 and SLF4J everywhere

commit 38df053d60467b587c0c7ec03f3368a84bf1cfea
Author: Steve Loughran 
Date:   2015-05-06T14:06:43Z

YARN-1564 -pick up enhancements/fixes from Slider-0.70-incubating versions 
of these classes

commit bf608f92a1c791c28fabf84dc2cca97daf35e1cf
Author: Steve Loughran 
Date:   2016-01-08T17:35:52Z

YARN-1564 turn off the findbugs warnings that are very much wrong




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [VOTE] Release Apache Hadoop 2.7.2 RC1

2016-01-08 Thread Akira AJISAKA 

The general rule sounds good to me.

> "any fix in 2.x.y to be there in all 2.b.c releases (while b>=x) that 
get out after 2.x.y release date"


+1

> I would prefer this rule only applies on critical/blocker fixes, but 
not applies on minor/trivial issues.


+1

Thanks,
Akira

On 12/29/15 23:50, Junping Du wrote:

I am +1 with pulling all of these tickets into 2.7.2.

- For “any fix in 2.6.3 to be there in all releases that get out after 2.6.3 
release date”

Shall we conclude this as a general rule - "any fix in 2.x.y to be there in all 2.b.c 
releases (while b>=x) that get out after 2.x.y release date"? I am generally fine 
with this, but just feel it sounds to set too strong restrictions among branches. Some fixes 
could be trivial (test case fix, etc.) enough to deserve more flexibility.​ I would prefer 
this rule only applies on critical/blocker fixes, but not applies on minor/trivial issues.

Just 2 cents.


Thanks,


Junping



From: Vinod Kumar Vavilapalli 
Sent: Thursday, December 24, 2015 12:47 AM
To: Junping Du
Cc: mapreduce-...@hadoop.apache.org; yarn-...@hadoop.apache.org; 
common-dev@hadoop.apache.org; hdfs-...@hadoop.apache.org
Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1

I retract my -1. I think we will need to discuss this a bit more.

Beyond those two tickets, there are a bunch more (totaling to 16) that are in 2.6.3 
but *not* in 2.7.2. See this: 
https://issues.apache.org/jira/issues/?jql=key%20in%20%28HADOOP-12526%2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CYARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPREDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0

Two options here, depending on the importance of ‘causality' between 2.6.x and 
2.7.x lines.
  - Ship 2.7.2 as we voted on here
  - Pull these 16 tickets into 2.7.2 and roll a new RC

What do people think? Do folks expect “any fix in 2.6.3 to be there in all 
releases that get out after 2.6.3 release date (December 16th)”?

Thanks
+Vinod

On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli 
mailto:vino...@apache.org>> wrote:

Sigh. Missed this.

To retain causality ("any fix in 2.6.3 will be there in all releases that got 
out after 2.6.3”), I’ll get these patches in.

Reverting my +1, and casting -1 for the RC myself.

Will spin a new RC, this voting thread is marked dead.

Thanks
+Vinod

On Dec 22, 2015, at 8:24 AM, Junping Du 
mailto:j...@hortonworks.com>> wrote:

However, when I look at our commit log and CHANGES.txt, I found something we 
are missing:
1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1 tag.
2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt

[jira] [Created] (HADOOP-12698) Set default Docker build uses JDK7

2016-01-08 Thread Kai Sasaki (JIRA) 
Kai Sasaki created HADOOP-12698:
---

 Summary: Set default Docker build uses JDK7
 Key: HADOOP-12698
 URL: https://issues.apache.org/jira/browse/HADOOP-12698
 Project: Hadoop Common
  Issue Type: Bug
Reporter: Kai Sasaki
Assignee: Kai Sasaki
Priority: Minor


The default JDK of build environment made by {{start-build-env.sh}} is JDK8 
from HADOOP-12562. Since current Hadoop trunk cannot be build by JDK8 
(HADOOP-11875), it is better to set the default JDK to JDK7 for now.



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

[jira] [Created] (HADOOP-12697) IPC retry policies should recognise that SASL auth failures are unrecoverable

2016-01-08 Thread Steve Loughran (JIRA) 
Steve Loughran created HADOOP-12697:
---

 Summary: IPC retry policies should recognise that SASL auth 
failures are unrecoverable
 Key: HADOOP-12697
 URL: https://issues.apache.org/jira/browse/HADOOP-12697
 Project: Hadoop Common
  Issue Type: Bug
  Components: ipc
Affects Versions: 2.7.1
 Environment: Cluster with kerberos on and client not calling with the 
right credentials
Reporter: Steve Loughran
Priority: Minor


SLIDER-1050 shows that if you don't have the right kerberos settings, the Yarn 
client IPC channel blocks retrying to the talk to the RM, retrying repeatedly

{noformat}
2016-01-07 02:50:45,111 [main] WARN  ipc.Client - Exception encountered while 
connecting to the server : javax.security.sasl.SaslException: GSS initiate 
failed [Caused by GSSException: No valid credentials provided (Mechanism level: 
Failed to find any Kerberos tgt)]
{noformat}

SASL exceptions need to be recognised as irreconcilable authentication 
failures, rather than generic IOEs that might go away if you retry



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

[jira] [Reopened] (HADOOP-12687) SecureUtil#getByName should also try to resolve direct hostname, incase multiple loopback addresses are present in /etc/hosts

2016-01-08 Thread Rohith Sharma K S (JIRA) 

 [ 
https://issues.apache.org/jira/browse/HADOOP-12687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohith Sharma K S reopened HADOOP-12687:


Reverted the issue commit, and reopening the issue. 

> SecureUtil#getByName should also try to resolve direct hostname, incase 
> multiple loopback addresses are present in /etc/hosts
> -
>
> Key: HADOOP-12687
> URL: https://issues.apache.org/jira/browse/HADOOP-12687
> Project: Hadoop Common
>  Issue Type: Bug
>Reporter: Junping Du
>Assignee: Sunil G
>  Labels: security
> Attachments: 0001-YARN-4352.patch, 0002-YARN-4352.patch, 
> 0003-HADOOP-12687.patch, 0004-HADOOP-12687.patch
>
>
> From 
> https://builds.apache.org/job/PreCommit-YARN-Build/9661/artifact/patchprocess/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-client-jdk1.7.0_79.txt,
>  we can see the tests in TestYarnClient, TestAMRMClient and TestNMClient get 
> timeout which can be reproduced locally.
> When {{/etc/hosts}} has multiple loopback entries, 
> {{InetAddress.getByName(null)}} will be returning the first entry present in 
> etc/hosts. Hence its possible that machine hostname can be second in list and 
> cause {{UnKnownHostException}}.
> Suggesting a direct resolve for such hostname scenarios.



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