Re: [DISCUSS] Merge Jersey upgrade(HADOOP-9613) to trunk

+1 agreed. > On May 9, 2016, at 2:13 PM, Akira AJISAKA wrote: > > +1 for marking HADOOP-9613 as incompatible change and upgrading the version > in trunk. > > Thanks, > Akira > > On 5/9/16 12:12, Tsuyoshi Ozawa wrote: >> Hi developers, >> >> We’ve worked on upgrading jersey(HADOOP-9613) for

Re: [DISCUSS] Set minimum version of Hadoop 3 to JDK8 (HADOOP-11858)

> On May 10, 2016, at 8:32 AM, Akira AJISAKA wrote: > > Hi developers, > > Before cutting 3.0.0-alpha RC, I'd like to drop JDK7 support in trunk. +1 yes please. > One concern I think is, when the minimum version is set to JDK8, we need to > configure Jenkins to disable multi JDK te

Re: [DISCUSS] Treating LimitedPrivate({"MapReduce"}) as Public APIs for YARN applications

> On May 10, 2016, at 8:37 AM, Hitesh Shah wrote: > > There have been various discussions on various JIRAs where upstream projects > such as YARN apps ( Tez, Slider, etc ) are called out for using the above > so-called Private APIs. A lot of YARN applications that have been built out > have p

Re: Compatibility guidelines for toString overrides

-1 without an audit of every toString usage. We have recent examples (e.g., HDFS-9732) where toString was used for output from CLI utilities. (which, IMO, should never have been done, but it’s too late now...) Output of CLI utilities is most definitely covered by the compatibility guidelines.

Re: Different JIRA permissions for HADOOP and HDFS

> On May 14, 2016, at 7:07 AM, Zheng, Kai wrote: > > Hi, > > Noticed this difference but not sure if it’s intended. YARN is similar with > HDFS. It’s not convenient. Any clarifying? Under JIRA, different projects (e.g., HADOOP, YARN, MAPREDUCE, HDFS, YETUS, HBASE, ACCUMULO, etc) ma

Re: [VOTE] Merge feature branch HADOOP-12930

h >> with and without bats installed), tried making an example custom >> command (valid and malformed). everything looks great. >> >> On Mon, May 9, 2016 at 1:26 PM, Allen Wittenauer wrote: >>> >>>Hey gang! >>> >>>I’d

Re: Compatibility guidelines for toString overrides

> On May 12, 2016, at 12:20 PM, Chris Nauroth wrote: > > Hello Allen, > > The intent is not for this rule to override other compatibility rules, > such as the important CLI output rule. It's also not intended to give us > free reign to change existing toString() implementations without due > d

Re: [VOTE] Merge feature branch HADOOP-12930

> On May 14, 2016, at 9:04 PM, Masatake Iwasaki > wrote: > > + hadoop_debug "Calling dynamically: hadoop_subcommand_${HADOOP_SUBCMD} > ${HADOOP_SUBCMD_ARGS[$*]}” Easy fix. The $* should just be *. I’ll open an issue and fix it here in a sec. Thanks!

Re: [VOTE] Merge feature branch HADOOP-12930

g overwhelmed since it would trigger full unit tests on pretty much the entire code base…. > While testing this, I discovered a bug in the distro build for Windows. > Could someone please code review my patch on HADOOP-13149? Done! > > --Chris Nauroth > > >

Re: [VOTE] Merge feature branch HADOOP-12930

> On May 15, 2016, at 7:27 AM, Allen Wittenauer wrote: > > >> On May 14, 2016, at 9:04 PM, Masatake Iwasaki >> wrote: >> >> + hadoop_debug "Calling dynamically: hadoop_subcommand_${HADOOP_SUBCMD} >> ${HADOOP_SUBCMD_ARGS[$*]}” > >

Re: [DISCUSS] Set minimum version of Hadoop 3 to JDK8 (HADOOP-11858)

There’s a bunch of stuff that needs to happen at the Jenkins level: * Kill off the JDK7 trunk builds for HADOOP, HDFS, MAPRED, YARN * Remove JDK7 from pre-commit for HADOOP, HDFS, MAPRED, YARN One thing that needs to happen in the Apache Yetus project: * Wait until YETUS-369 has been written and

[RESULT] Re: [VOTE] Merge feature branch HADOOP-12930

Vote passes. 1 = +1 non-binding 4 = +1 binding I’ll squash and commit here in a sec. Thanks everyone! - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.ap

Re: [DISCUSS] Set minimum version of Hadoop 3 to JDK8 (HADOOP-11858)

OK, it looks like if someone commits HADOOP-13161, then trunk only uses JDK8 and branch-2 will use JDK7 and JDK8 during precommit with no changes required to Apache Yetus. :D > On May 16, 2016, at 5:38 PM, Allen Wittenauer > wrote: > > > There’s a bunch of stuf

Re: [DISCUSS] Set minimum version of Hadoop 3 to JDK8 (HADOOP-11858)

t 8:02 PM, Allen Wittenauer wrote: > > OK, it looks like if someone commits HADOOP-13161, then trunk only uses > JDK8 and branch-2 will use JDK7 and JDK8 during precommit with no changes > required to Apache Yetus. :D > > >> On May 16, 2016, at 5:38 PM,

Re: Tons of "javac: invalid target release: 1.8" failures happen on YARN precommit runs

> On May 17, 2016, at 10:54 AM, Wangda Tan wrote: > > Hi YARN-dev/Common-dev, > > I noticed lots of "javac: invalid target release: 1.8" failures happen on > YARN precommit runs since yesterday, not sure if other projects like HDFS > face the same issue. > > Filed HADOOP-13167 to track the iss

Re: [DISCUSS] upgrade tomcat from 6.0.44 to 6.0.45 and use non apache.org mirror

> On May 17, 2016, at 2:08 PM, Wangda Tan wrote: > > Then I investigated a little more, there're two issues from what I can see > 1) If you look at http://archive.apache.org/dist/, it clearly says: > *> Please do not download from apache.org !* > > 2) And also, http://archive

Re: Different JIRA permissions for HADOOP and HDFS

t;> > >>>>> >>> > >>>>> On Mon, May 16, 2016 at 1:21 AM, Zhihai Xu >>mailto:zhi...@uber.com>> >>> wrote: >>> > >>>>> >>> > >>>>> Currently

Re: [DISCUSS] upgrade tomcat from 6.0.44 to 6.0.45 and use non apache.org mirror

> On May 17, 2016, at 8:32 PM, Wangda Tan wrote: > > I'm not sure if archive.apache.org enforces some new bandwidth limit > policies recently, I haven't seen such bandwidth limits before. We should > consider to fix it If more people complaint about such failures. Chances are, either:

Re: Hadoop CI with alternate architectures.

That’s really a question for infrastructure-...@apache.org . They manage the ASF build infrastructure which Apache Hadoop and lots of other projects utilize. (Bigtop uses something custom, which I think is funded by Cloudera.) Once it is registered with builds.apache.org, it’

Re: Build failed in Jenkins: Hadoop-common-trunk-Java8 #1502

looks like H3 is about to collapse. > On May 18, 2016, at 10:55 AM, Apache Jenkins Server > wrote: > > See > > -- > [...truncated 4 lines...] > Cloning repository https://git-wip-us.apache.

ASF OS X Build Infrastructure

Some of you may not know that the ASF actually does have an OS X machine (a Mac mini, so it’s not a speed demon) in the build infrastructure. While messing around with getting all? of the trunk jobs reconfigured to do Java 8 and separate maven repos, I noticed that this box ten

Re: [DISCUSS] upgrade tomcat from 6.0.44 to 6.0.45 and use non apache.org mirror

Some potential ways to fix this: a) Move away from tomcat to one of the other two? three? maybe even four? application servers that are already in the Apache Hadoop build b) Move to embedded tomcat so that the jars, etc, get downloaded as part of the maven build Either

Re: About fix versions

> On May 28, 2016, at 5:13 PM, Zheng, Kai wrote: > > Hi, > > This may be a stupid question but I want to make sure. What fix versions > would we fill with when a committer just wants to commit a patch to trunk or > branch-2 branch? This is covered on the https://wiki.apache.org/hadoo

Re: About fix versions

> On May 29, 2016, at 5:16 AM, Zheng, Kai wrote: > > Thanks Allen a lot. This is comprehensive. > >>> So if a patch has been committed to branch-2.8, branch-2, and trunk, then >>> the fix version should be 2.8.0 and only 2.8.0. > This sounds like the right rule I seem to need and want to kn

[DISCUSS] Replacing the automatic Jenkins jobs with Apache Yetus qbt

Hey gang. I’ve been thinking a lot over the past few months about the various Jenkins jobs that we have that run after a commit. Their job is to tell us when a commit break a unit test. They eat up an incredible amount of time on the build infrastructure and I’m not really sure if the

Re: [DISCUSS] Replacing the automatic Jenkins jobs with Apache Yetus qbt

> On May 31, 2016, at 8:53 PM, Andrew Wang wrote: > > I'm in favor of something that helps unify the current mess of Jenkins > jobs. We do something similar for our internal Hadoop repo: each branch has > a "build.sh" and "test.sh" script that builds and then runs the tests. This > predates Yetu

Re: [DISCUSS] Replacing the automatic Jenkins jobs with Apache Yetus qbt

> On Jun 1, 2016, at 10:51 AM, Chris Nauroth wrote: > It looks like Failed junit tests removes the "org.apache" prefix, but > Timed out junit tests does not. If possible, it would be nice for this to > be consistent. Ha. It's been that way in Yetus for a very, very long time. I've ope

Re: [DISCUSS] Replacing the automatic Jenkins jobs with Apache Yetus qbt

Thanks all. As soon as YETUS-390 gets committed, I'll start publishing the reports to *-dev. FWIW, here's last night's. It makes it easy to find out now when committers are opening ignoring findbugs warnings. (The latest from YARN-5180. It started showing up yesterday.) For more details

Re: [DISCUSS] Replacing the automatic Jenkins jobs with Apache Yetus qbt

ems. (e.g., the PowerPC bits) > On Jun 3, 2016, at 12:50 PM, Chris Nauroth wrote: > > I think the new formatting makes it a lot easier to pick out a specific > log file link. Thank you for making that change. > > --Chris Nauroth > > > > > On 6/3/16, 7:53 A

Re: Cannot create release artifacts for branch-2.8

> On Jun 6, 2016, at 10:50 PM, Wangda Tan wrote: > > Hi Hadoop Devs, > > As you know, we're pushing 2.8.0 releases recently, there're couple of > issues that block creating release artifacts from source code. > > I tried following approaches: > 1) Run build through Hadoop Jenkins Job: http:/

Re: Cannot create release artifacts for branch-2.8

> On Jun 7, 2016, at 11:37 AM, Wangda Tan wrote: > > I have tested both, create-releases fails on my local box as well. > > According to the link you provided, we probably need to update how to > release wiki > . I'm working on

Re: Cannot create release artifacts for branch-2.8

> On Jun 7, 2016, at 1:44 PM, Wangda Tan wrote: > > That gonna be very helpful, but I guess it only works on trunk, correct? At > least many of the parameters you mentioned are not in create-release.sh of > branch-2. Yup. create-release was rewritten in trunk. The previous version had

Re: Pre-commit Docker image build failures on H2?

You guys know that the build machines in the Yahoo data center temporarily lose network all the time, right? It's been happening for months now... > On Jun 8, 2016, at 9:53 AM, Anu Engineer wrote: > > Another instance of the same failure. > > https://builds.apache.org/job/PreCommi

Re: Pre-commit Docker image build failures on H2?

> On Jun 8, 2016, at 10:09 AM, Anu Engineer wrote: > > Sorry did not know about the network. Is it possible to have Java > pre-installed in the docker image? Nope. Licensing issues. > Are downloading only Java from the net, because all of the cases are Oracle > Java install failure w

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

> On Jun 17, 2016, at 7:04 AM, Apache Jenkins Server > wrote: > > For more details, see > https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/66/ > I suspect this change: > [Jun 16, 2016 11:17:06 AM] (vinayakumarb) HDFS-10256. Use > GenericTestUtils.getTestDir method i

Re: Apache Hadoop 2.5.0 published tarballs are missing some txt files

2.5.1 should fix HADOOP-10986 as well. On Aug 20, 2014, at 4:29 PM, Arun Murthy wrote: > +1. > > Thanks Karthik. > > Arun > > > On Wed, Aug 20, 2014 at 4:25 PM, Karthik Kambatla > wrote: > >> Thanks for the suggestions, gents. >> >> Given we are doing 2.5.1, I would like to get in HADO

Re: Updates on migration to git

RE: —author No, we should not do this. This just increases friction. It’s hard enough getting patches reviewed and committed, esp if you are not @apache.org. Trying to dig up a valid address (nevermind potentially having to deal with 'nsf...@example.com') is just asking for trouble. Plus, the JI

Re: Updates on migration to git

Did a build. Started some stuff. Have a patch ready to be committed. ;) Thanks Karthik and Daniel! On Aug 26, 2014, at 2:26 PM, Karthik Kambatla wrote: > I compared the new asf git repo against the svn and github repos (mirrored > from svn). Here is what I see: > - for i in *; do git diff $i

Re: migrating private branches to the new git repo

On Sep 3, 2014, at 11:07 AM, Chris Douglas wrote: > > As long as release notes and incompatible changes are recorded in each > branch, we gain no accuracy by maintaining this manually. Commit > messages that record the merge revisions instead of the change are > similarly hateful. -C We’ll als

Re: migrating private branches to the new git repo

On Sep 3, 2014, at 11:42 AM, Allen Wittenauer wrote: > > On Sep 3, 2014, at 11:07 AM, Chris Douglas wrote: > >> >> As long as release notes and incompatible changes are recorded in each >> branch, we gain no accuracy by maintaining this manually. Commit >&g

Re: migrating private branches to the new git repo

t; generates a changelog for a release. We could then use that to make sure > the various fields are set properly for previous releases, remove > CHANGES.txt once we're confident, and then use said script to generate the > changelog for future releases. > > > On Wed, S

Re: migrating private branches to the new git repo

OK, it does, but only under certain conditions. Hmm. On Sep 3, 2014, at 12:04 PM, Allen Wittenauer wrote: > > > Looks like the web UI doesn't allow for bulk change of Fix Version. > > *cries* > > On Sep 3, 2014, at 11:56 AM, Andrew Wang wrote: > >>

Re: migrating private branches to the new git repo

d to filter on 'Fixed' as well, given duplicates and won't fixed and invalids listed w/a fix version as well. On Sep 3, 2014, at 12:10 PM, Allen Wittenauer wrote: > > OK, it does, but only under certain conditions. Hmm. > > On Sep 3, 2014, at 12:04 PM, Allen Wittenauer

Re: migrating private branches to the new git repo

0.0. However the target version would be 2.x.0 as > that is the earliest release that includes the fix. > > > On Wed, Sep 3, 2014 at 12:45 PM, Allen Wittenauer wrote: > >> >> Figured it out. Basically can only do bulk fix version edits of one >> project at a ti

Re: migrating private branches to the new git repo

> > On Wed, Sep 3, 2014 at 1:01 PM, Allen Wittenauer wrote: > >> I was doing that too, but I went "to the source": >> >> https://wiki.apache.org/hadoop/HowToCommit says: >> >> "Resolve the issue as fixed, thanking the contributor. Always set the

Re: migrating private branches to the new git repo

On Sep 3, 2014, at 4:57 PM, Chris Douglas wrote: > On Wed, Sep 3, 2014 at 11:42 AM, Allen Wittenauer wrote: >> We’ll also need to get much more strict about Fix Version really only >> listing the earliest version. Many of list (next release) + (trunk), myself >>

auto-generating changes.txt was: migrating private branches to the new git repo

Nothing official or clean or whatever, but just to give people an idea of what an auto generated CHANGES.txt file might look like, here are some sample runs of the hacky thing I built, based upon the fixVersion information. It doesn't break it down by improvement, etc. Also, the name on the en

Re: auto-generating changes.txt was: migrating private branches to the new git repo

p 3, 2014 at 6:51 PM, Allen Wittenauer wrote: > >> Nothing official or clean or whatever, but just to give people an idea of >> what an auto generated CHANGES.txt file might look like, here are some >> sample runs of the hacky thing I built, based upon the fixVersion >

Re: auto-generating changes.txt was: migrating private branches to the new git repo

Oh, it's in hdfs. Sneaky. On Sep 3, 2014, at 7:10 PM, Allen Wittenauer wrote: > > I don't see HADOOP-10957 in hadoop-common-project/hadoop-cmmon/CHANGES.txt on > github in the 2.5.1 branch. > > On Sep 3, 2014, at 7:00 PM, Karthik Kambatla wrote: > >>

Re: auto-generating changes.txt was: migrating private branches to the new git repo

lly incompatible —but it is still good to > highlight the things we know are likely to cause trouble > > > On 4 September 2014 02:51, Allen Wittenauer wrote: > >> Nothing official or clean or whatever, but just to give people an idea of >> what an auto generated CHAN

Re: auto-generating changes.txt was: migrating private branches to the new git repo

On Sep 5, 2014, at 9:19 AM, Karthik Kambatla wrote: > On Thu, Sep 4, 2014 at 8:37 AM, Allen Wittenauer wrote: >> >>We do need to have a talk about 3.x though. Looking over the >> list, it would appear that a lot of (what became) early 2.x JIRAs were >>

Re: auto-generating changes.txt was: migrating private branches to the new git repo

FWIW, I’ve gone through a 2nd pass of JIRA for 3.0.0. I’m reasonable confident that as of this very second that the 155 non-sub-tasks are only in trunk. I did not do a pass over the 35 sub-tasks claiming to be in 3.x. Fun fact: the oldest patch is from 2011 and turned 3 years old this month.

Re: auto-generating changes.txt was: migrating private branches to the new git repo

Fixed the subtasks. Hacked on my changes generator a bit more. Source is in my github repo if anyone wants to play with it. Here’s a (merged) 3.x changes.txt file from the current output built off of JIRA. (The unmerged versions are also created, but look pretty much identical.) http://pas

Re: auto-generating changes.txt was: migrating private branches to the new git repo

On Sep 10, 2014, at 6:17 PM, Allen Wittenauer wrote: > Here’s a (merged) 3.x changes.txt file from the current output built off of > JIRA. (The unmerged versions are also created, but look pretty much > identical.) > > http://pastebin.com/fEUKSDG4 Woops, that’s only comm

In hindsight... Re: Thinking ahead to hadoop-2.6

It’s now September. With the passage of time, I have a lot of doubts about this plan and where that trajectory takes us. * The list of changes that are already in branch-2 scare the crap out of any risk adverse person (Hello to my fellow operations people!). Not only are the number of

Re: In hindsight... Re: Thinking ahead to hadoop-2.6

On Sep 15, 2014, at 11:17 AM, Colin McCabe wrote: > On Mon, Sep 15, 2014 at 10:48 AM, Allen Wittenauer wrote: >> >>It’s now September. With the passage of time, I have a lot of doubts >> about this plan and where that trajectory takes us. >> >&g

Re: [DISUCSS] Reasonable Hadoop ACL Defaults

Removing security@ , adding hdfs-dev@ . On Sep 16, 2014, at 1:19 AM, Zhijie Shen wrote: > Hi folks, > > There're a bunch of ACLs configuration defaults, which are set to "*": > > 1. yarn.admin.acl in yarn-default.xml > 2. > yarn.scheduler.capacity.root.default.[acl_submit_applications|acl_ad

Re: In hindsight... Re: Thinking ahead to hadoop-2.6

On Sep 17, 2014, at 2:47 AM, Steve Loughran wrote: > > I don't agree. Certainly the stuff I got into Hadoop 2.5 nailed down the > filesystem binding with more tests than ever before. FWIW, based upon my survey of JIRA, there are a lot of unit test fixes that are only in trunk. > But

Re: [ANNOUNCE] Apache Hadoop 3.0.0 GA is released

It’s significantly more concerning that 3.0.0-beta1 doesn’t show up here: http://hadoop.apache.org/docs/r3.0.0/hadoop-project-dist/hadoop-common/release/index.html It looks like they are missing from the source tag too. I wonder what else is missing. > On Dec 18, 2017, at 11:15 AM, Andrew Wa

Re: PreCommit-Admin fails to fetch issue list from jira

FWIW, the new JIRA has broken a few things thus far. Akira fixed an issue with test-patch and I’ve got a fix for precommit-admin as part of YETUS-594. As soon as it and YETUS-592 gets a review+commit, I’ll start the 0.7.0 release process. Also, as a reminder, Apache Yetus uses +1’s from cont

Re: PreCommit-Admin fails to fetch issue list from jira

> On Jan 16, 2018, at 1:27 PM, Vihang Karajgaonkar wrote: > > Hive pre-commit jobs are broken as well since the JIRA upgrade. Did you have > to make any changes to hadoop-precommit job to make it work? Any pointers > will help us fix ours as well. Until precommit-admin gets fixed, no

Re: PreCommit-Admin fails to fetch issue list from jira

> On Jan 16, 2018, at 1:41 PM, Vihang Karajgaonkar wrote: > > yes, thats correct. I had created > https://issues.apache.org/jira/browse/INFRA-15849 to get that fixed. But > looks like based on the comment there we need to modify that job to use REST > instead of SOAP? I think there

Switched PreCommit-Admin over to Apache Yetus

bcc: bui...@apache.org, d...@hbase.apache.org, d...@hive.apache.org, common-dev@hadoop.apache.org, d...@phoenix.apache.org, d...@oozie.apache.org (These are all of the projects that had pending issues. This is not all of the groups that actually rely upon this code...) The rece

Fwd: Apache Hadoop qbt Report: trunk+JDK8 on Windows/x64

For my part of the HDFS bug bash, I’ve gotten the ASF Windows build working again. Starting tomorrow, results will be sent to the *-dev lists. A few notes: * It only runs the unit tests. There’s not much point in running the other Yetus plugins since those are covered by the Linux one

Re: [NOTIFICATION] Hadoop trunk rebased

Did the patch that fixes the mountain of maven warnings get missed? > On Apr 26, 2018, at 11:52 PM, Akira Ajisaka wrote: > > + common-dev and mapreduce-dev > > On 2018/04/27 6:23, Owen O'Malley wrote: >> As we discussed in hdfs-dev@hadoop, I did a force push to Hadoop's trunk to >> replace the

Re: Apache Hadoop qbt Report: branch2+JDK7 on Linux/x86

FYI: I’m going to disable the branch-2 nightly jobs. - To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Re: Apache Hadoop qbt Report: branch2+JDK7 on Linux/x86

> On May 15, 2018, at 10:16 AM, Chris Douglas wrote: > > They've been failing for a long time. It can't install bats, and > that's fatal? -C The bats error is new and causes the build to fail enough that it produces the email output. For the past few months, it hasn’t been producing

Re: [VOTE] Release Apache Hadoop 3.0.3 (RC0)

> On Jun 7, 2018, at 3:46 AM, Lokesh Jain wrote: > > Hi Yongjun > > I followed Nanda’s steps and I see the same issues as reported by Nanda. This situation is looking like an excellent opportunity for PMC members to mentor people on how the build works since it’s apparent that three days la

Re: [VOTE] Release Apache Hadoop 3.0.3 (RC0)

> On Jun 7, 2018, at 11:47 AM, Steve Loughran wrote: > > Actually, Yongjun has been really good at helping me get set up for a 2.7.7 > release, including "things you need to do to get GPG working in the docker > image” *shrugs* I use a different release script after some changes broke

Re: [DISCUSS] Alpha Release of Ozone

Given that there are some Ozone components spread out past the core maven modules, is the plan to release a Hadoop Trunk + Ozone tar ball or is more work going to go into segregating the Ozone components prior to release? Has anyone verified that a Hadoop release doesn't have _any_ of the extr

Re: [DISCUSS] Alpha Release of Ozone

> On Aug 8, 2018, at 12:56 PM, Anu Engineer wrote: > >> Has anyone verified that a Hadoop release doesn't have _any_ of the extra >> ozone bits that are sprinkled outside the maven modules? > As far as I know that is the state, we have had multiple Hadoop releases > after ozone has been merg

Re: Checkstyle shows false positive report

> On Aug 15, 2018, at 4:49 AM, Kitti Nánási > wrote: > > Hi All, > > We noticed that the checkstyle run by the pre commit job started to show > false positive reports, so I created HADOOP-15665 > . > > Until that is fixed, keep in mind to r

Re: ${!var} In Scripts

> On Mar 1, 2019, at 3:04 PM, Daniel Templeton wrote: > > There are a bunch of uses of the bash syntax, "${!var}", in the Hadoop > scripts. Can anyone explain to me what that syntax was supposed to achieve? #!/usr/bin/env bash j="hi" m="bye" k=j echo ${!k} k=m echo ${!k}

Re: ${!var} In Scripts

> On Mar 4, 2019, at 9:33 AM, Daniel Templeton wrote: > > Thanks! That's not even close to what the docs suggest it does--no idea > what's up with that. It does. Here’s the paragraph: "If the first character of parameter is an exclamation point (!), a level of variable indirection

Re: ${!var} In Scripts

> On Mar 4, 2019, at 10:00 AM, Daniel Templeton wrote: > > Do you want to file a JIRA for it, or shall I? Given I haven’t done any Hadoop work in months and months … - To unsubscribe, e-mail: common-dev-unsubscr...

Re: [DICUSS] Upgrading Guice to 4.0(HADOOP-12064)

> On Jun 29, 2016, at 10:16 AM, Tsuyoshi Ozawa wrote: > > No objections here? I talked to a handful of non-committer ISV-type folks yesterday and the general consensus was that there is an expectation that 3.x will have all the dependencies updated to something relatively modern if we can't

Re: Assign my Jira to myself?

> On Jul 11, 2016, at 9:41 AM, Poepping, Thomas wrote: > > Hi common-dev@, > > I’m finding I can’t assign my own Jira, > https://issues.apache.org/jira/browse/HADOOP-13344 to myself. > > Is there a list I need to be on to do that? Or can someone do it for me? Done. --

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

I've already asked on builds and infra if it was related to some other changes they made. As usual, radio silence. On the flip side, the PPC machines are making builds and in many ways might be more valuable. e.g., pointing out that the leveldb changes in YARN have pretty much completely b

Re: [DISCUSS] The order of classpath isolation work and updating/shading dependencies on trunk

Does any of this work actually help processes that sit outside of YARN? > On Jul 21, 2016, at 12:29 PM, Sean Busbey wrote: > > thanks for bringing this up! big +1 on upgrading dependencies for 3.0. > > I have an updated patch for HADOOP-11804 ready to post this week. I've > been updating HBase

Re: [DISCUSS] 2.6.x line releases

> On Jul 21, 2016, at 5:06 PM, Zhe Zhang wrote: > > We are using 2.6 releases and would like to see 2.6.5. > > One related issue, pre-commit is not working for 2.6 (see comment from > Allen > https://issues.apache.org/jira/browse/HDFS-10653?focusedCommentId=15388621&page=com.atlassian.jira.plug

Re: Setting JIRA fix versions for 3.0.0 releases

From the perspective of an end user who is reading multiple versions' listings at once, listing the same JIRA being fixed in multiple releases is totally confusing, especially now that release notes are actually readable. "So which version was it ACTUALLY fixed in?" is going to be the

Re: [DISCUSS] 2.6.x line releases

> On Jul 22, 2016, at 9:07 AM, Zhe Zhang wrote: > > Thanks Allen for the note. I thought the 2.6 Dockerfile issue was addressed > in https://issues.apache.org/jira/browse/HADOOP-12800? 2.6 builds on JDK6 and JDK7. 2.x, where x>6, builds on JDK7 and JDK8. [1] This should have been a big red

Re: [DISCUSS] The order of classpath isolation work and updating/shading dependencies on trunk

nly* helps processes that sit outside of YARN. :) > > On Fri, Jul 22, 2016 at 10:48 AM, Allen Wittenauer > wrote: > > > > Does any of this work actually help processes that sit outside of YARN? > > > >> On Jul 21, 2016, at 12:29 PM, Sean Busbey wrote: > >

Re: Setting JIRA fix versions for 3.0.0 releases

> On Jul 22, 2016, at 7:16 PM, Andrew Wang wrote: > > Does this mean you find our current system of listing a JIRA as being fixed > in both a 2.6.x and 2.7.x to be confusing? Nope. I'm only confused when there isn't a .0 release in the fix line. When I see 2.6.x and 2.7.x I know tha

Re: [DISCUSS] The order of classpath isolation work and updating/shading dependencies on trunk

> On Jul 22, 2016, at 5:47 PM, Zheng, Kai wrote: > > For the leveldb thing, wouldn't we have an alternative option in Java for the > platforms where leveldb isn't supported yet due to whatever reasons. IMO, > native library would be best to be used for optimization and production for > perfor

Re: [DISCUSS] The order of classpath isolation work and updating/shading dependencies on trunk

> On Jul 25, 2016, at 1:16 PM, Sangjin Lee wrote: > > Also: right now, the non-Linux and/or non-x86 platforms have to supply their > own leveldbjni jar (or at least the C level library?) in order to make YARN > even functional. How is that going to work with the class path manipulation? > >

Re: Wiki migration and clean-up

I hope you folks are aware that this is much more intensive than just moving a bunch of documents. Lots of wiki pages are referenced in the source code, including in user-facing error messages. > On Jul 28, 2016, at 10:47 AM, Ray Chiang wrote: > > Thanks Martin. I did ask on INFRA-

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

Re: [Release thread] 2.6.5 release activities

> 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

Re: [Release thread] 2.6.5 release activities

> On Aug 12, 2016, at 8:19 AM, Junping Du wrote: > > In this community, we are so aggressive to drop Java 7 support in 3.0.x > release. Here, why we are so conservative to keep releasing new bits to > support Java 6? I don't view a group of people putting bug fixes into a micro relea

Re: [VOTE] Release Apache Hadoop 2.7.3 RC1

-1 HDFS-9395 is an incompatible change: a) Why is not marked as such in the changes file? b) Why is an incompatible change in a micro release, much less a minor? c) Where is the release note for this change? > On Aug 12, 2016, at 9:45 AM, Vinod Kumar Vavilapalli > wrote: > > Hi all, > > I

Re: [VOTE] Release Apache Hadoop 2.7.3 RC1

t; exception cases. I think it still belongs to 2.7.3 scope. > Kuhu and Kihwal, any comments here? > > > Thanks, > > Junping > > From: Allen Wittenauer > Sent: Wednesday, August 17, 2016 5:29 AM > To: common-dev@hadoop.ap

Re: Merge IPv6

> On Aug 19, 2016, at 4:38 PM, Elliott Clark wrote: > > HADOOP-11890 Is the related jira. I've added some comments to that JIRA regarding an actual code issue. But I have a general question that probably isn't appropriate for the JIRA (yet?). Way back in the 0.20 days, the NN didn't handle

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

> On Aug 26, 2016, at 7:55 AM, Apache Jenkins Server > wrote: > > >Failed CTEST tests : > > test_test_libhdfs_threaded_hdfs_static > test_test_libhdfs_zerocopy_hdfs_static Something here likely broke these tests: [Aug 24, 2016 7:47:52 AM] (aajisaka) HADOOP-13538. Deprecat

Re: jdk 9 early access

> On Aug 28, 2016, at 4:27 AM, Steve Loughran wrote: > > who is bold enough to set up a no-emails-please jenkins build of Hadoop & > Java 9? We already know it won't work. (log4j) - To unsubscribe, e-mail: common-

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha1 RC0

> On Aug 30, 2016, at 10:17 AM, Zhe Zhang wrote: > > Thanks Andrew for the great work! It's really exciting to finally see a > Hadoop 3 RC. > > I noticed CHANGES and RELEASENOTES markdown files which were not in > previous RCs like 2.7.3. What are good tools to verify them? I tried > reading th

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha1 RC0

> On Aug 30, 2016, at 2:06 PM, Eric Badger > wrote: > > > WARNING: log4j.properties is not found. HADOOP_CONF_DIR may be incomplete. ^^ > > After running the above command, the RM UI showed a successful job, but as > you can see, I did not have anything pri

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha1 RC0

> On Aug 30, 2016, at 2:20 PM, Eric Badger wrote: > > Well that's embarrassing. I had accidentally slightly renamed my > log4j.properties file in my conf directory, so it was there, just not being > read. Nah. You were just testing out the shell rewrite's ability to detect a common

[DISCUSS] HADOOP-13341 Merge Request

Before requesting a merge vote, I'd like for folks to take a look at HADOOP-13341. This branch changes how the vast majority of the _OPTS variables work in various ways, making things easier for devs and users by helping to make the rules consistent. It also clarifies/cleans up how the _USER

Re: [VOTE] Release Apache Hadoop 3.0.0-alpha1 RC0

> On Sep 1, 2016, at 2:57 PM, Andrew Wang wrote: > > Steve requested a git hash for this release. This led us into a brief > discussion of our use of git tags, wherein we realized that although > release tags are immutable (start with "rel/"), RC tags are not. This is > based on the HowToRelease

<    1   2   3   4   5   6   7   8   9   10   >