[jira] [Resolved] (HDFS-7033) dfs.web.authentication.filter should be documented

[ https://issues.apache.org/jira/browse/HDFS-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-7033. Resolution: Won't Fix > dfs.web.authentication.filter should be do

[jira] [Resolved] (HDFS-7231) rollingupgrade needs some guard rails

[ https://issues.apache.org/jira/browse/HDFS-7231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-7231. Resolution: Won't Fix > rollingupgrade needs some gua

[jira] [Resolved] (HDFS-7307) Need 'force close'

[ https://issues.apache.org/jira/browse/HDFS-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-7307. Resolution: Won't Fix > Need 'force close' > -- &g

[jira] [Resolved] (HDFS-7777) Consolidate the HA NN documentation down to one

[ https://issues.apache.org/jira/browse/HDFS-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-. Resolution: Won't Fix > Consolidate the HA NN documentation dow

[jira] [Resolved] (HDFS-7850) distribute-excludes and refresh-namenodes update to new shell framework

[ https://issues.apache.org/jira/browse/HDFS-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-7850. Resolution: Won't Fix Target Version/s: (was: ) > distribute-excl

[jira] [Resolved] (HDFS-7904) NFS hard codes ShellBasedIdMapping

[ https://issues.apache.org/jira/browse/HDFS-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-7904. Resolution: Won't Fix > NFS hard codes ShellBasedI

[jira] [Resolved] (HDFS-7983) HTTPFS proxy server needs pluggable-auth support

[ https://issues.apache.org/jira/browse/HDFS-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-7983. Resolution: Won't Fix Target Version/s: (was: ) > HTTPFS proxy serv

[jira] [Resolved] (HDFS-9055) WebHDFS REST v2

[ https://issues.apache.org/jira/browse/HDFS-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-9055. Resolution: Won't Fix Target Version/s: (was: ) > WebHDFS

[jira] [Resolved] (HDFS-9058) enable find via WebHDFS

[ https://issues.apache.org/jira/browse/HDFS-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-9058. Resolution: Won't Fix Target Version/s: (was: ) > enable find via

[jira] [Resolved] (HDFS-9031) libhdfs should use doxygen plugin to generate mvn site output

[ https://issues.apache.org/jira/browse/HDFS-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-9031. Resolution: Won't Fix > libhdfs should use doxygen plugin to generate mvn sit

[jira] [Resolved] (HDFS-9056) add set/remove quota capability to webhdfs

[ https://issues.apache.org/jira/browse/HDFS-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-9056. Resolution: Won't Fix Target Version/s: (was: ) > add set/remo

[jira] [Resolved] (HDFS-9059) Expose lssnapshottabledir via WebHDFS

[ https://issues.apache.org/jira/browse/HDFS-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-9059. Resolution: Won't Fix Target Version/s: (was: ) > Expose lssnapshottabl

[jira] [Resolved] (HDFS-9061) hdfs groups should be exposed via WebHDFS

[ https://issues.apache.org/jira/browse/HDFS-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-9061. Resolution: Won't Fix Target Version/s: (was: ) > hdfs groups should be

[jira] [Resolved] (HDFS-9464) Documentation needs to be exposed

[ https://issues.apache.org/jira/browse/HDFS-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-9464. Resolution: Won't Fix > Documentation needs to be

[jira] [Resolved] (HDFS-9465) No header files in mvn package

[ https://issues.apache.org/jira/browse/HDFS-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-9465. Resolution: Won't Fix > No header files in mvn

[jira] [Resolved] (HDFS-9778) Add liberasurecode support

[ https://issues.apache.org/jira/browse/HDFS-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-9778. Resolution: Won't Fix > Add liberasurecode

[jira] [Resolved] (HDFS-10509) httpfs generates docs in bin tarball

[ https://issues.apache.org/jira/browse/HDFS-10509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-10509. - Resolution: Won't Fix > httpfs generates docs in bin

[jira] [Reopened] (HDFS-11356) figure out what to do about hadoop-hdfs-project/hadoop-hdfs/src/main/native

[ https://issues.apache.org/jira/browse/HDFS-11356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer reopened HDFS-11356: - > figure out what to do about hadoop-hdfs-project/hadoop-hdfs/src/main/nat

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: [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: [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: [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: [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: 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: Apache Hadoop qbt Report: branch2+JDK7 on Linux/x86

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

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

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

[jira] [Resolved] (HDFS-7913) HADOOP_HDFS_LOG_DIR should be HDFS_LOG_DIR in deprecations

[ https://issues.apache.org/jira/browse/HDFS-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-7913. Resolution: Won't Fix > HADOOP_HDFS_LOG_DIR should be HDFS_LOG_DIR in depr

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: [VOTE] Release Apache Hadoop 3.0.0 RC0

> On Nov 30, 2017, at 1:07 AM, Rohith Sharma K S > wrote: > > > >. If ATSv1 isn’t replaced by ATSv2, then why is it marked deprecated? > Ideally it should not be. Can you point out where it is marked as deprecated? > If it is in historyserver daemon start, that change made very long back when

Re: [VOTE] Release Apache Hadoop 3.0.0 RC0

> On Nov 21, 2017, at 2:16 PM, Vinod Kumar Vavilapalli > wrote: > >>> - $HADOOP_YARN_HOME/sbin/yarn-daemon.sh start historyserver doesn't even >>> work. Not just deprecated in favor of timelineserver as was advertised. >> >> This works for me in trunk and the bash code doesn’t appear to

Re: [VOTE] Release Apache Hadoop 3.0.0 RC0

The original release script and instructions broke the build up into three or so steps. When I rewrote it, I kept that same model. It’s probably time to re-think that. In particular, it should probably be one big step that even does the maven deploy. There’s really no harm in doing th

Re: [DISCUSSION] Merging HDFS-7240 Object Store (Ozone) to trunk

> On Nov 3, 2017, at 12:08 PM, Stack wrote: > > On Sat, Oct 28, 2017 at 2:00 PM, Konstantin Shvachko > wrote: > >> It is an interesting question whether Ozone should be a part of Hadoop. > > I don't see a direct answer to this question. Is there one? Pardon me if > I've not seen it but I'm in

[jira] [Created] (HDFS-12743) Fix env vars (again)

Allen Wittenauer created HDFS-12743: --- Summary: Fix env vars (again) Key: HDFS-12743 URL: https://issues.apache.org/jira/browse/HDFS-12743 Project: Hadoop HDFS Issue Type: Sub-task

[jira] [Created] (HDFS-12711) deadly hdfs test

Allen Wittenauer created HDFS-12711: --- Summary: deadly hdfs test Key: HDFS-12711 URL: https://issues.apache.org/jira/browse/HDFS-12711 Project: Hadoop HDFS Issue Type: Test

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

> On Oct 24, 2017, at 4:10 PM, Andrew Wang wrote: > > FWIW we've been running branch-3.0 unit tests successfully internally, though > we have separate jobs for Common, HDFS, YARN, and MR. The failures here are > probably a property of running everything in the same JVM, which I've found > pro

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

t tell which daemons/components of HDFS consumes unexpected high >> memory. Don't sounds like a solid bug report to me. >> >> >> >> Thanks,? >> >> >> Junping >> >> >> >> From: Sean Bus

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

> On Oct 23, 2017, at 12:50 PM, Allen Wittenauer > wrote: > > > > With no other information or access to go on, my current hunch is that one of > the HDFS unit tests is ballooning in memory size. The easiest way to kill a > Linux machine is to eat all of the RAM,

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

. > > Thanks, > Subru > > On Mon, Oct 23, 2017 at 11:26 AM, Vrushali C wrote: > Hi Allen, > > I have filed https://issues.apache.org/jira/browse/YARN-7380 for the > timeline service findbugs warnings. > > thanks > Vrushali > > > On Mon, Oct 23, 2017

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

I’m really confused why this causes the Yahoo! QA boxes to go catatonic (!?!) during the run. As in, never come back online, probably in a kernel panic. It’s pretty consistently in hadoop-hdfs, so something is going wrong there… is branch-2 hdfs behaving badly? Someone needs to run the hadoop

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

To whoever set this up: There was a job config problem where the Jenkins branch parameter wasn’t passed to Yetus. Therefore both of these reports have been against trunk. I’ve fixed this job (as well as the other jobs) to honor that parameter. I’ve kicked off a new run with these changes.

YARN native services Re: 2017-10-06 Hadoop 3 release status update

> On Oct 6, 2017, at 5:51 PM, Eric Yang wrote: > yarn application -deploy –f spec.json > yarn application -stop > yarn application -restart > yarn application -remove > > and > > yarn application –list will display both application list from RM as well as > docker services?

Re: 2017-10-06 Hadoop 3 release status update

> On Oct 6, 2017, at 1:31 PM, Andrew Wang wrote: > > - Still waiting on Allen to review YARN native services feature. Fake news. I’m still -1 on it, at least prior to a patch that posted late yesterday. I’ll probably have a chance to play with it early next week. Key pro

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

> On Sep 19, 2017, at 6:35 AM, Brahma Reddy Battula > wrote: > > qbt is failing from two days with following errors, any idea on this..? Nothing to be too concerned about. This is what it looks like when a build server gets bounced or crashed. INFRA team knows our jobs take

Re: [VOTE] Merge yarn-native-services branch into trunk

> On Sep 8, 2017, at 9:25 AM, Jian He wrote: > > Hi Allen, > The documentations are committed. Please check QuickStart.md and others in > the same folder. > YarnCommands.md doc is updated to include new commands. > DNS default port is also documented. > Would you like to give a look and see if

Re: [VOTE] Merge yarn-native-services branch into trunk

> On Sep 5, 2017, at 6:23 PM, Jian He wrote: > >> If it doesn’t have all the bells and whistles, then it shouldn’t be on >> port 53 by default. > Sure, I’ll change the default port to not use 53 and document it. >> *how* is it getting launched on a privileged port? It sounds like the

Re: [VOTE] Merge yarn-native-services branch into trunk

> On Sep 5, 2017, at 3:12 PM, Gour Saha wrote: > > 2) Lots of markdown problems in the NativeServicesDiscovery.md document. > This includes things like Œyarnsite.xml¹ (missing a dash.) > > The md patch uploaded to YARN-5244 had some special chars. I fixed those > in YARN-7161. It’s a

Re: [VOTE] Merge yarn-native-services branch into trunk

> On Sep 5, 2017, at 2:53 PM, Jian He wrote: > >> Based on the documentation, this doesn’t appear to be a fully function DNS >> server as an admin would expect (e.g., BIND, Knot, whatever). Where’s >> forwarding? How do I setup notify? Are secondaries even supported? etc, etc. > > It seems l

Re: [VOTE] Merge yarn-native-services branch into trunk

> On Aug 31, 2017, at 8:33 PM, Jian He wrote: > I would like to call a vote for merging yarn-native-services to trunk. 1) Did I miss it or is there no actual end-user documentation on how to use this? I see hadoop-yarn-project/hadoop-yarn/hadoop-yarn-site/src/site/markdown/native-serv

YARN javadoc failures Re: [DISCUSS] Branches and versions for Hadoop 3

> On Aug 28, 2017, at 9:58 AM, Allen Wittenauer > wrote: > The automation only goes so far. At least while investigating Yetus > bugs, I've seen more than enough blatant and purposeful ignored errors and > warnings that I'm not convinced it will be effectiv

Re: [DISCUSS] Branches and versions for Hadoop 3

> On Aug 28, 2017, at 12:41 PM, Jason Lowe wrote: > > I think this gets back to the "if it's worth committing" part. This brings us back to my original question: "Doesn't this place an undue burden on the contributor with the first incompatible patch to prove worthiness? What

Re: [DISCUSS] Branches and versions for Hadoop 3

> On Aug 25, 2017, at 1:23 PM, Jason Lowe wrote: > > Allen Wittenauer wrote: > > > Doesn't this place an undue burden on the contributor with the first > > incompatible patch to prove worthiness? What happens if it is decided that > > it's not g

[jira] [Resolved] (HDFS-12253) CLONE - Pretty-format the output for DFSIO

[ https://issues.apache.org/jira/browse/HDFS-12253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-12253. - Resolution: Duplicate Fix Version/s: (was: 3.0.0-alpha1

[jira] [Reopened] (HDFS-12253) CLONE - Pretty-format the output for DFSIO

[ https://issues.apache.org/jira/browse/HDFS-12253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer reopened HDFS-12253: - > CLONE - Pretty-format the output for DF

Re: [DISCUSS] Branches and versions for Hadoop 3

> On Aug 25, 2017, at 10:36 AM, Andrew Wang wrote: > Until we need to make incompatible changes, there's no need for > a Hadoop 4.0 version. Some questions: Doesn't this place an undue burden on the contributor with the first incompatible patch to prove worthiness? What happens if it

Re: Branch merges and 3.0.0-beta1 scope

We should avoid turning this into a replay of Apache Hadoop 2.6.0 (and to a lesser degree, 2.7.0 and 2.8.0) where a bunch of last minute “experimental” features derail stability for a significantly long period of time. -

Re: Why aren't delegation token operations audit logged?

On 2017-08-14 11:52, Xiao Chen wrote: > When inspecting the code, I found that the following methods in > FSNamesystem are not audit logged: ... > I checked with ATM hoping for some history, but no known to him. Anyone > know the reason to not audit log these? The audit log was de

Re: Are binary artifacts are part of a release?

-general/20.mbox/%3C4EB0827C.6040204%40apache.org%3E > > Doug Cutting: > "Folks should not primarily evaluate binaries when voting. The ASF primarily > produces and publishes source-code > so voting artifacts should be optimized for evaluation of that." > > Thanks, &g

Re: Are binary artifacts are part of a release?

> On Jul 31, 2017, at 4:18 PM, Andrew Wang wrote: > > Forking this off to not distract from release activities. > > I filed https://issues.apache.org/jira/browse/LEGAL-323 to get clarity on the > matter. I read the entire webpage, and it could be improved one way or the > other. IAN

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

> On Jul 31, 2017, at 11:20 AM, Konstantin Shvachko > wrote: > > https://wiki.apache.org/hadoop/HowToReleasePreDSBCR FYI: If you are using ASF Jenkins to create an ASF release artifact, it's pretty much an automatic vote failure as any such release is in violation of

[jira] [Created] (HDFS-12220) hdfs' parallel tests don't work for Windows

Allen Wittenauer created HDFS-12220: --- Summary: hdfs' parallel tests don't work for Windows Key: HDFS-12220 URL: https://issues.apache.org/jira/browse/HDFS-12220 Project: Hadoop HDFS

Re: Pre-Commit build is failing

; >> > >> Should we add "patchprocess/" to .gitignore, is that the problem for 2.7? > >> > >> Thanks, > >> --Konstantin > >> > >> On Fri, Jul 21, 2017 at 6:24 PM, Konstantin Shvachko < > >> shv.had...@gmail.com>

Re: Pre-Commit build is failing

> On Jul 21, 2017, at 5:46 PM, Konstantin Shvachko wrote: > > + d...@yetus.apache.org > > Guys, could you please take a look. Seems like Yetus problem with > pre-commit build for branch-2.7. branch-2.7 is missing stuff in .gitignore. ---

[jira] [Created] (HDFS-11972) cblockserver uses wrong OPT env var

Allen Wittenauer created HDFS-11972: --- Summary: cblockserver uses wrong OPT env var Key: HDFS-11972 URL: https://issues.apache.org/jira/browse/HDFS-11972 Project: Hadoop HDFS Issue Type

[jira] [Resolved] (HDFS-11599) distcp interrupt does not kill hadoop job

[ https://issues.apache.org/jira/browse/HDFS-11599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HDFS-11599. - Resolution: Not A Problem Yes. The program running on the command line is just a client

Re: About 2.7.4 Release

Is there any reason to not Close -alpha1+resolved state JIRAs? It's been quite a while and those definitely should not getting re-opened anymore. What about -alpha2's that are also resolved? - To unsubscribe, e-mail: hdfs-dev-

Re: About 2.7.4 Release

> On May 1, 2017, at 2:27 PM, Andrew Wang wrote: > I believe I asked about this on dev-yetus a while back. I'd prefer that the > presence of the fix version be sufficient to indicate whether a JIRA is > included in a release branch. Yetus requires that the JIRA be resolved as > "Fixed" to show

[jira] [Created] (HDFS-11724) libhdfs compilation is broken on OS X

Allen Wittenauer created HDFS-11724: --- Summary: libhdfs compilation is broken on OS X Key: HDFS-11724 URL: https://issues.apache.org/jira/browse/HDFS-11724 Project: Hadoop HDFS Issue Type

Re: About 2.7.4 Release

> On Apr 25, 2017, at 12:35 AM, Akira Ajisaka wrote: > > Maybe we should create a jira to track this? > > I think now either way (reopen or create) is fine. > > Release doc maker creates change logs by fetching information from JIRA, so > reopening the tickets should be avoided when a release

Re: HADOOP-14316: Switching from Findbugs to Spotbugs

> On Apr 19, 2017, at 10:52 AM, Wei-Chiu Chuang wrote: > That sounds scary. Would you mind to share the list of bugs that spotbugs > found? Sounds like some of them may warrant new blockers jiras for Hadoop 3. I've added the list to the JIRA. ---

HADOOP-14316: Switching from Findbugs to Spotbugs

Hey gang. HADOOP-14316 enables the spotbugs back-end for the findbugs front-end. Spotbugs (https://spotbugs.github.io/) is the fork of findbugs that the community and some of the major contributors have made to move findbugs forward. It is geared towards JDK8 and JDK9. Befor

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

Looks like someone reset HEAD back to Mar 31. Sent from my iPad > On Apr 16, 2017, at 12:08 AM, Apache Jenkins Server > wrote: > > For more details, see > https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/378/ > > > > > > -1 overall > > > The following subsystems voted -1

Re: Hadoop QA fails with "Docker failed to build yetus/hadoop:a9ad5d6"

> On Apr 13, 2017, at 11:13 PM, Arun Suresh wrote: > > Yup, > > YARN Pre-Commit tests are having the same problem as well. > Is there anything that can be done to fix this ? Ping Yetus folks (Allen / > Sean) https://issues.apache.org/jira/browse/HADOOP-14311 --

Re: [DISCUSS] Changing the default class path for clients

;s the current contract for `hadoop classpath`? Would it be safer to > introduce `hadoop userclasspath` or similar for this behavior? > > I'm betting that changing `hadoop classpath` will lead to some breakages, > so I'd prefer to make this new behavior opt-in. > > Best,

[DISCUSS] Changing the default class path for clients

This morning I had a bit of a shower thought: With the new shaded hadoop client in 3.0, is there any reason the default classpath should remain the full blown jar list? e.g., shouldn’t ‘hadoop classpath’ just return configuration, user supplied bits (e.g., HADOOP_USER_CLASSPAT

Re: Can we update protobuf's version on trunk?

> On Mar 28, 2017, at 5:09 PM, Chris Douglas wrote: > > I haven't seen data identifying PB as a bottleneck, but the > non-x86/non-Linux and dev setup arguments may make this worthwhile. -C FWIW, we have the same problem with leveldbjni-all. (See the ASF PowerPC build logs) I keep meani

Re: [RESULT] [VOTE] Release Apache Hadoop 2.8.0 (RC3)

Just a heads up. Looks like some removed the Finish Date off of 2.8.0 in JIRA. It needs to be put back to match what is in the artifacts that we voted on. - To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org For add

Re: [VOTE] Release Apache Hadoop 2.8.0 (RC3)

> On Mar 21, 2017, at 10:12 AM, Andrew Wang wrote: > > I poked around a bit. The 3.0.0-alpha2 binary tarball is only 246M and has > more changes than 2.8.0. Not to disclaim any other potential issues, but it's worth noting 3.x de-dupes jar files as part of the packaging process. So it's not

Re: About 2.7.4 Release

> On Mar 8, 2017, at 1:54 PM, Allen Wittenauer > wrote: > > This is already possible: > * don’t use —asfrelease > * use —sign, —native, and, if appropriate for your platform, > —docker and —dockercache Oh yeah, I forg

Re: About 2.7.4 Release

> On Mar 8, 2017, at 10:55 AM, Marton Elek wrote: > > I think the main point here is the testing of the release script, not the > creation of the official release. … except the Hadoop PMC was doing exactly this from 2.3.0 up until recently. Which means we have a few years worth of rel

Re: About 2.7.4 Release

> On Mar 7, 2017, at 2:51 PM, Andrew Wang wrote: > I think it'd be nice to > have a nightly Jenkins job that builds an RC, Just a reminder that any such build cannot be used for an actual release: http://www.apache.org/legal/release-policy.html#owned-controlled-hardware

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

> On Jan 23, 2017, at 8:50 PM, Chris Douglas wrote: > > Thanks for all your work on this, Andrew. It's great to see the 3.x > series moving forward. > > If you were willing to modify the release notes and add the LICENSE to > the jar, we don't need to reset the clock on the VOTE, IMO. FWIW, I

Re: [VOTE] Release cadence and EOL

> On Jan 21, 2017, at 7:08 PM, Karthik Kambatla wrote: > > 3. RM: some method to madness. Junping, for instance, is trying to roll > a release with 2300 patches. It is a huge time investment. (Thanks again, > Junping.) Smaller releases are easier to manage. A target release cadence, > co

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

> On Jan 22, 2017, at 9:05 PM, Allen Wittenauer > wrote: > > > > > >> On Jan 20, 2017, at 2:36 PM, Andrew Wang wrote: >> >> http://home.apache.org/~wang/3.0.0-alpha2-RC0/ > > There are quite a few JIRA issues that need release notes.

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

> On Jan 20, 2017, at 2:36 PM, Andrew Wang wrote: > > http://home.apache.org/~wang/3.0.0-alpha2-RC0/ There are quite a few JIRA issues that need release notes. - To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.

[jira] [Created] (HDFS-11356) figure out what to do about hadoop-hdfs-project/hadoop-hdfs/src/main/native

Allen Wittenauer created HDFS-11356: --- Summary: figure out what to do about hadoop-hdfs-project/hadoop-hdfs/src/main/native Key: HDFS-11356 URL: https://issues.apache.org/jira/browse/HDFS-11356

Re: [Continued] [Release thread] 2.8.0 release activities

If you ran mvn clean at any point in your repo between create-release and mvn deploy, you'll need to start at running create-release again. create-release leaves things in a state that mvn deploy should be ready to go, with no clean necessary. > On Jan 20, 2017, at 11:12 AM, Junping Du wrote

Re: [VOTE] Release cadence and EOL

> On Jan 18, 2017, at 11:21 AM, Chris Trezzo wrote: > > Thanks Sangjin for pushing this forward! I have a few questions: These are great questions, because I know I'm not seeing a whole lot of substance in this vote. The way to EOL software in the open source universe is with new rel

Re: [VOTE] Release Apache Hadoop 2.6.5 (RC1)

> On Oct 6, 2016, at 1:39 PM, Akira Ajisaka wrote: > > > It wasn't 'renamed' to jenkins, prior releases were actually built by and > > on the Jenkins infrastructure. Which was a very very bad idea: it's > > insecure and pretty much against ASF policy. > > Sorry for the confusion. I should no

Re: [VOTE] Release Apache Hadoop 2.6.5 (RC1)

> On Oct 5, 2016, at 10:35 PM, Akira Ajisaka wrote: > Can we rename it? > > AFAIK, hadoop releases were built by hortonmu in 2014 and was renamed to > jenkins. That's not how that works. It's literally storing the id of the person who built the classes. It wasn't 'renamed' t

Re: HADOOP-13636 and io.bytes.per.checksum

> On Sep 24, 2016, at 5:11 AM, Allen Wittenauer > wrote: > > >> On Sep 24, 2016, at 4:24 AM, Steve Loughran wrote: >> >> >> On 23 Sep 2016, at 18:55, Andrew Wang >> mailto:andrew.w...@cloudera.com>> wrote: >> >> Have you git b

Re: HADOOP-13636 and io.bytes.per.checksum

> On Sep 24, 2016, at 4:24 AM, Steve Loughran wrote: > > > On 23 Sep 2016, at 18:55, Andrew Wang > mailto:andrew.w...@cloudera.com>> wrote: > > Have you git blamed to dig up the original JIRA conversation? I think that > deprecation predates many of us, so you might not get much historical

[RESULTS] Re: [VOTE] Merge HADOOP-13341

The vote passes with 3 +1 binding votes. I'll be merging this later today. Thanks everyone! > On Sep 7, 2016, at 6:44 AM, Allen Wittenauer > wrote: > > > I’d like to call for a vote to run for 5 days (ending Mon 12, 2016 at > 7AM PT) to merge the HADOOP-13

Re: [VOTE] Merge HADOOP-13341

> On Sep 9, 2016, at 2:15 PM, Anu Engineer wrote: > > +1, Thanks for the effort. It brings in a world of consistency to the hadoop > vars; and as usual reading your bash code was very educative. Thanks! There's still a handful of HDFS and MAPRED vars that begin with HADOOP, b

Re: [VOTE] Merge HADOOP-13341

> On Sep 8, 2016, at 2:50 AM, Steve Loughran wrote: > > I'm trying to do the review effort here even though I don't know detailed > bash, as I expect I don't know any less than others, and what better way to > learn than reviewing code written by people that do know bash? Just a head

[VOTE] Merge HADOOP-13341

I’d like to call for a vote to run for 5 days (ending Mon 12, 2016 at 7AM PT) to merge the HADOOP-13341 feature branch into trunk. This branch was developed exclusively by me. As usual with large shell script changes, it's been broken up into several smaller commits to make it easier

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

> On Sep 1, 2016, at 3:18 PM, Allen Wittenauer > wrote: > > >> 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 al

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

[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 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

  1   2   3   4   5   6   >