tion of configs - potentially separating client side
> configs
> >> and those used by daemons. This is another source of perpetual confusion
> >> for users.
> >>
> >> Thanks
> >> - Sid
> >>
> >>
> >> On Thu, Mar 5, 2015 at 2:46 PM, S
IMO, if part of the community wants to take on the responsibility and work
that takes to do a new major release, we should not discourage them from
doing that.
Having multiple major branches active is a standard practice.
This time around we are not replacing the guts as we did from Hadoop 1 to
H
IMO we should:
1* have a clean and thin client API JAR (which does not drag any 3rd party
dependencies, or a well defined small set -i.e. slf4j & log4j-)
2* have a client implementation that uses a classloader to isolate client
impl 3rd party deps from app dependencies.
#2 can be done using a sto
Alejandro Abdelnur created MAPREDUCE-6101:
-
Summary: on job submission, if input or output directories are
encrypted, shuffle data should be encrypted at rest
Key: MAPREDUCE-6101
URL: https
--
Alejandro
Thanks Karthik.
+1.
+ verified MD5 for source tarball
+ verified signature for source tarball
+ successfully run apache-rat:check
+ checked CHANGES, LICENSE, README, NOTICE files.
+ built from source tarball
+ started pseudo cluster
+ run a couple of MR example jobs
+ basic test on HttpFS
On Wed
Alejandro Abdelnur created MAPREDUCE-6060:
-
Summary: shuffle data should be encrypted at rest if the
input/output of the job are in an encryption zone
Key: MAPREDUCE-6060
URL: https://issues.apache.org
I've just did some work on top of trunk and branch-2, all good.
Thanks Karthik.
On Tue, 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 ../hadoop-githu
Verified MD5s and signatures of both SRC & BIN tarballs.
Thanks Karthik.
On Mon, Aug 18, 2014 at 12:42 PM, Karthik Kambatla
wrote:
> Hi devs
>
> Tsuyoshi just brought it to my notice that the published tarballs don't
> have LICENSE, NOTICE and README at the top-level. Instead, they are only
>
+1
Alejandro
(phone typing)
> On Aug 8, 2014, at 19:57, Karthik Kambatla wrote:
>
> I have put together this proposal based on recent discussion on this topic.
>
> Please vote on the proposal. The vote runs for 7 days.
>
> 1. Migrate from subversion to git for version control.
> 2. Force-
funny, i'd treat it as a merge vote.
On Fri, Aug 8, 2014 at 11:44 AM, Karthik Kambatla
wrote:
> Thanks Steve. Including that in the proposal.
>
> By the way, from our project bylaws (http://hadoop.apache.org/bylaws.html
> ),
> I can't tell what kind of a vote this would be.
>
>
> On Thu, Aug 7,
+1
+ verified MD5 for source tarball
+ verified signature for source tarball
+ successfully run apache-rat:check
+ checked CHANGES.txt files
+ built from source tarball
+ started pseudo cluster
+ run a couple of MR example jobs
+ basic test on HttpFS
On Wed, Aug 6, 2014 at 2:45 PM, Ted Yu wrote
+0, (see 2 '-' below). I think we should address those and cut a new RC.
+ verified MD5 for source tarball
+ verified signature for source tarball
+ successfully run apache-rat:check
- CHANGES.txt have 'Release 2.5.0 - UNRELEASED' they should have 'Release
2.5.0 - '
- HDFS CHANGES.txt has HDFS-675
I would say we can first move to git and keep the very same workflow we
have today, then we can evolve it.
On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal
wrote:
> +1 to voting on specific workflow(s).
>
>
> On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla
> wrote:
>
> > If we are to start a vot
+1, we did it for Oozie a while back and was painless with minor issues in
Jenkins jobs
Rebasing feature branches on latest trunk may be tricky as that may require
a force push and if I'm not mistaken force pushes are disabled in Apache
GIT.
thx
On Fri, Aug 1, 2014 at 4:43 PM, Karthik Kambatla
[
https://issues.apache.org/jira/browse/MAPREDUCE-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur resolved MAPREDUCE-5890.
---
Resolution: Fixed
Fix Version/s: fs-encryption
Hadoop Flags
> What's in branch-2.4.1 doesn't currently match what's in this RC,
but there is a tag that matches, right? Else we need to fix that.
On Fri, Jun 27, 2014 at 3:26 PM, Aaron T. Myers wrote:
> That's fine by me. Like I said, assuming that rc1 does indeed include the
> fix in HDFS-6527, and not t
; Hortonworks
> http://hortonworks.com/
>
>
>
> On Wed, Jun 25, 2014 at 9:48 AM, Owen O'Malley wrote:
>
> > On Tue, Jun 24, 2014 at 4:44 PM, Alejandro Abdelnur
> > wrote:
> >
> > > After reading this thread and thinking a bit about it, I t
After reading this thread and thinking a bit about it, I think it should be
OK such move up to JDK7 in Hadoop 2 for the following reasons:
* Existing Hadoop 2 releases and related projects are running
on JDK7 in production.
* Commercial vendors of Hadoop have already done lot of
work to ensure
On Fri, Jun 20, 2014 at 10:02 PM, Arun C Murthy wrote:
> > Hadoop 3.x out the door later this year
>
> +1 that makes sense to me. Thanks for volunteering Steve - I'm glad to
> share the pain… ;-)
Hey Arun, you may have missed that Andrew volunteered for doing this as
well (the thread is long,
+1
verified checksum & signature on SRC TARBALL
verified CHANGES.txt files
run apache-rat:check on SRC
build SRC
installed pseudo cluster
run successfully a few MR sample jobs
verified HttpFS
Thanks Arun
On Mon, Jun 16, 2014 at 9:27 AM, Arun C Murthy wrote:
> Folks,
>
> I've created a releas
Alejandro Abdelnur created MAPREDUCE-5890:
-
Summary: Support for encrypting Intermediate data and spills in
local filesystem
Key: MAPREDUCE-5890
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5890
[
https://issues.apache.org/jira/browse/MAPREDUCE-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur resolved MAPREDUCE-4658.
---
Resolution: Won't Fix
[doing self-clean up of JIRAs] scripts have c
[
https://issues.apache.org/jira/browse/MAPREDUCE-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur resolved MAPREDUCE-2608.
---
Resolution: Invalid
[doing self-clean up of JIRAs] closing as invalid as
Trying to run the PI MapReduce example using RC0 the job is failing,
looking at the NM logs I'm getting the following.
I believe it may be something in my setup as many already test MR jobs with
this RC successfully, but couldn't figure out yet. Running on OSX 10.9.1
using JDK7.
Thanks.
--
Running pseudo cluster out of the box (expanding the binary tar, or
building from source) does not work, you have to go an set the MR framework
to yarn, the default FS URI to hdfs://localhost:8020, and so on.
While I don't see this as showstopper (for the knowledgeable user), it will
make may user
sire, as sandy said, lets keep it in branch 2 for now and if not resolved by
2.4 timeframe we'll revert them there.
thx
Alejandro
(phone typing)
> On Feb 7, 2014, at 10:14, Steve Loughran wrote:
>
>> On 6 February 2014 17:07, Alejandro Abdelnur wrote:
>>
>&
care of those issues.
>
> +1 for going ahead with the revert on branch-2.3. I'll go do that tomorrow
> morning unless I hear otherwise from Jian.
>
> Thanks,
> +Vinod
>
>
> On Feb 6, 2014, at 8:28 PM, Alejandro Abdelnur wrote:
>
> > Hi Vinod,
> >
>
t decision.
>
> There is the issue with unmanaged AM that is clearly known and I was
> thinking of coming to the past two days, but couldn't. What is this new
> issue that we (confidently?) pinned down to YARN-1490?
>
> Thanks
> +Vinod
>
> On Feb 6, 2014, at 5:07 PM, Ale
roblem caused by YARN-1493 I think we can revert it in branch-2.3 as well.
>>
>> I think we should leave them in branch-2 for now. We can revert if 2.4 is
>> imminent and they're holding it up, but hopefully the issues they caused
>> will be fixed by then.
> >
> > >
> > > On Wed, Feb 5, 2014 at 4:49 PM, Arpit Agarwal <
> aagar...@hortonworks.com
> > > >wrote:
> > >
> > > > IMO HADOOP-10273 (Fix 'mvn site') should be included in 2.3.
> > > >
> > > > I will merge it to
IMO YARN-1577 is a blocker, it is breaking unmanaged AMs in a very odd ways
(to the point it seems un-deterministic).
I'd say eiher YARN-1577 is fixed or we revert
YARN-1493/YARN-1490/YARN-1166/YARN-1041/YARN-1566 (almost clean reverts)
from Hadoop 2.3 branch before doing the release.
I've verif
*All,*
The Apache Jenkins job to build release artifacts for Hadoop 2 is ready (in
its first incarnation). The job URL is:
https://builds.apache.org/job/HADOOP2_Release_Artifacts_Builder/
I hope this will make moot all concerns about user accounts and about the
hardware ownership being used to
I agree on not auto-signing (the script does not do it, on purpose).
I was referring to deploying release artifact JARs.
OK, then we are done then.
Thanks.
On Thu, Jan 30, 2014 at 5:02 PM, Roman Shaposhnik wrote:
> On Thu, Jan 30, 2014 at 4:43 PM, Alejandro Abdelnur
> wrote:
> &
[Cross-posting with https://issues.apache.org/jira/browse/HADOOP-10313]
OK, we have:
* A script, create-release.sh, that creates release artifacts
* An Apache Jenkins job that runs the script and produces the artifacts in
Apache CI machines, thanks Yahoo! (or shouldn't I say that?)
The Apache Je
Alejandro Abdelnur created MAPREDUCE-5724:
-
Summary: JobHistoryServer does not start if HDFS is not running
Key: MAPREDUCE-5724
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5724
[
https://issues.apache.org/jira/browse/MAPREDUCE-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur resolved MAPREDUCE-5722.
---
Resolution: Invalid
false alarm, it seems I was picking up some stale
Alejandro Abdelnur created MAPREDUCE-5722:
-
Summary: client-app module failing to compile, missing jersey
dependency
Key: MAPREDUCE-5722
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5722
Chris,
I'm already on it.
Thanks.
On Fri, Dec 6, 2013 at 9:49 AM, Chris Nauroth wrote:
> +1 for the idea. The branch committership clause was added for exactly
> this kind of scenario.
>
> From the phrasing in the bylaws, it looks like we'll need assistance from
> PMC to get the ball rolling.
Sound goods, just a little impedance between what seem to be 2 conflicting
goals:
* what features we target for each release
* train releases
If we want to do train releases at fixed times, then if a feature is not
ready, it catches the next train, no delays of the train because of a
feature. If
Cheers.
Alejandro
Commits in branch-2.2 that I'd like them to be in the 2.2.1 release:
The ones prefixed with '*' technically are not bugs.
YARN-1284. LCE: Race condition leaves dangling cgroups entries for killed
The following is happening in builds for MAPREDUCE and YARN patches.
I've seen the failures in hadoop5 and hadoop7 machines. I've increased
Maven memory to 1GB (export MAVEN_OPTS="-Xmx1024m" in the jenkins
jobs) but still some failures persist:
https://builds.apache.org/job/PreCommit-MAPREDUCE-Buil
+1
* downloaded source tarball
* verified MD5
* verified signature
* verified CHANGES.txt files, release # and date
* run 'mvn apache-rat:check' successfully
* built distribution
* setup speudo cluster
* started HDFS/YARN
* run some HTTFS tests
* run a couple of MR examples
* run a few tests using
Arun,
Does this mean that you want to skip a beta release and go straight to GA
with the next release?
thx
On Tue, Oct 1, 2013 at 4:15 PM, Arun C Murthy wrote:
> Guys,
>
> I took a look at the content in 2.1.2-beta so far, other than the
> critical fixes such as HADOOP-9984 (symlinks) and fe
ping
On Tue, Sep 24, 2013 at 2:36 AM, Alejandro Abdelnur wrote:
> Vote for the 2.1.1-beta release is closing tonight, while we had quite a
> few +1s, it seems we need to address the following before doing a release:
>
> symlink discussion: get a concrete and explicit understandin
Vote for the 2.1.1-beta release is closing tonight, while we had quite a
few +1s, it seems we need to address the following before doing a release:
symlink discussion: get a concrete and explicit understanding on what we
will do and in what release(s).
Also, the following JIRAs seem nasty enough
Are we doing a new RC for 2.1.1-beta?
On Mon, Sep 23, 2013 at 9:04 PM, Vinod Kumar Vavilapalli wrote:
> Correct me if I am wrong, but FWIU, we already released a beta with the
> same symlink issues. Given 2.1.1 is just another beta, I believe we can go
> ahead with it and resolve the issues in
On Wed, Sep 18, 2013 at 12:03 AM, Karthik Kambatla wrote:
> Not sure if this should be a blocker for 2.1.1, but filed HADOOP-9976 to
> have a single version of avro.
>
>
It depends if there is a known and non-workaroundable issue at runtime
because of this. If not I wouldn't say it is a blocker.
Thanks Arun.
+1
* Downloaded source tarball.
* Verified MD5
* Verified signature
* run apache-rat:check ok after minor tweak (see NIT1 below)
* checked CHANGES.txt headers (see NIT2 below)
* built DIST from source
* verified hadoop version of Hadoop JARs
* configured pseudo cluster
* tested HttpF
[
https://issues.apache.org/jira/browse/MAPREDUCE-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur resolved MAPREDUCE-5379.
---
Resolution: Fixed
Fix Version/s: 2.1.1-beta
Hadoop Flags
Alejandro Abdelnur created MAPREDUCE-5483:
-
Summary: revert MAPREDUCE-5357
Key: MAPREDUCE-5483
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5483
Project: Hadoop Map/Reduce
Alejandro Abdelnur created MAPREDUCE-5473:
-
Summary: JT webservices use a static SimpleDateFormat,
SImpleDateFormat is not threadsafe
Key: MAPREDUCE-5473
URL: https://issues.apache.org/jira/browse
+1
Downloaded source tarball
Verified MD5
Verified Signature
Run apache-rat:check
Did a dist build
Started pseudo cluster
Run a couple of MR examples
Tested HttpFS
On Thu, Aug 15, 2013 at 10:29 PM, Konstantin Boudnik wrote:
> All,
>
> I have created a release candidate (rc1) for hadoop-2.0.6
release and upload rc1
> right now.
>
> Please let me know if you feel like we need start doing the license for the
> releasenotes in this release.
>
> Thanks,
> Cos
>
> On Wed, Aug 14, 2013 at 10:40AM, Alejandro Abdelnur wrote:
> > OK:
> > * verified MD
forgot to add: A big thanks to Rajiv and Giri for helping out with the
changes in the Jenkins boxes.
On Wed, Aug 14, 2013 at 4:03 PM, Alejandro Abdelnur wrote:
> Following up on this.
>
> HADOOP-9845 & HADOOP-9872 have been committed
> to trunk/branch-2/branch-2.1-beta/b
Following up on this.
HADOOP-9845 & HADOOP-9872 have been committed
to trunk/branch-2/branch-2.1-beta/branch-2.1.0-beta.
All Hadoop developers must install protoc 2.5.0 in their development
machines for the build to run.
All Hadoop jenkins boxes are using protoc 2.5.0
The BUILDING.txt file has
test-patch came back.
I'll commit to trunk and all "2" branches.
Once done I'll send an email indicating new protoc is required for
development.
Thanks.
On Wed, Aug 14, 2013 at 10:51 AM, Alejandro Abdelnur wrote:
> I've filed https://issues.apache.org/jira/browse/
On Tue, Aug 13, 2013 at 1:09 PM, Alejandro Abdelnur wrote:
>
> There is no indication that protoc 2.5.0 is breaking anything.
>
> Hadoop-trunk builds have been failing way before 1/2 way with:
>
> ---
>
>
> [ERROR] Failed to execute goal
> org.apache.maven
OK:
* verified MD5
* verified signature
* expanded source tar and did a build
* configured pseudo cluster and run a couple of example MR jobs
* did a few HTTP calls to HTTFS
NOT OK:
* CHANGES.txt files have 2.0.6 as UNRELEASED, they should have the date the
RC vote ends
* 'mvn apache-rat:check' fa
2, 2013 at 8:35 PM, Alejandro Abdelnur wrote:
> Jenkins is running a full test run on trunk using protoc 2.5.0.
>
> https://builds.apache.org/job/Hadoop-trunk/480
>
> And it seems go be going just fine.
>
> If everything looks OK, I'm planing to backport HADOOP-9845 to
lures do the protoc mismatch.
Thanks.
Alejandro
On Mon, Aug 12, 2013 at 5:53 PM, Alejandro Abdelnur wrote:
> shooting to get it i n for 2.1.0.
>
> at moment is in trunk till the nightly finishes. then we'll decide
>
> in the mean time, you can have multiple versions install
gt; I did not get definite impression there is.
> If not it could be a pretty big disruption.
>
> Thanks,
> --Konst
>
>
>
> On Mon, Aug 12, 2013 at 3:19 PM, Alejandro Abdelnur wrote:
>
>> I've just committed HADOOP-9845 to trunk (only trunk at the moment).
>
.
On Mon, Aug 12, 2013 at 2:57 PM, Alejandro Abdelnur wrote:
> About to commit HADOOP-9845 to trunk, in 5 mins. This will make trunk use
> protoc 2.5.0.
>
> thx
>
>
> On Mon, Aug 12, 2013 at 11:47 AM, Giridharan Kesavan <
> gkesa...@hortonworks.com> wrote:
>
>&g
x 2.0 branch builds as well.
> Thoughts?
>
> -Giri
>
>
> On Mon, Aug 12, 2013 at 11:37 AM, Alejandro Abdelnur >wrote:
>
> > Giri,
> >
> > first of all, thanks for installing protoc 2.5.0.
> >
> > I didn't know we were installing them as the
is upgraded from 2.4 to 2.5. 2.5 is in the default path.
> If we still need 2.4 I may have to install it. Let me know
>
> -Giri
>
>
> On Sat, Aug 10, 2013 at 7:01 AM, Alejandro Abdelnur >wrote:
>
> > thanks giri, how do we set 2.4 or 2.5., what is the path to
> On Fri, Aug 9, 2013 at 10:56 PM, Giridharan Kesavan <
> gkesa...@hortonworks.com> wrote:
>
>> Alejandro,
>>
>> I'm upgrading protobuf on slaves hadoop1-hadoop9.
>>
>> -Giri
>>
>>
>> On Fri, Aug 9, 2013 at 1:15 PM, Alejandro
pinging again, I need help from somebody with sudo access to the hadoop
jenkins boxes to do this or to get sudo access for a couple of hours to set
up myself.
Please!!!
thx
On Thu, Aug 8, 2013 at 2:29 PM, Alejandro Abdelnur wrote:
> To move forward with this we need protoc 2.5.0 in the apa
Sent: Thursday, August 8, 2013 1:59 AM
> > Subject: Re: Upgrade to protobuf 2.5.0 for the 2.1.0 release, HADOOP-9845
> >
> >
> > Hi,
> >
> > About Hadoop, Harsh is dealing with this problem in HADOOP-9346.
> > For more detail, please see the JIRA
I' like to upgrade to protobuf 2.5.0 for the 2.1.0 release.
As mentioned in HADOOP-9845, Protobuf 2.5 has significant benefits to
justify the upgrade.
Doing the upgrade now, with the first beta, will make things easier for
downstream projects (like HBase) using protobuf and adopting Hadoop 2. If
Thanks Arun,
+1
* verified MD5 & signature of source tarball.
* built from source tarball
* run apache-rat:check on source
* installed pseudo cluster (unsecure)
* test httpfs
* run pi example
* run unmanaged AM application
Minor NITs (in case we do a new RC):
* remove 2.1.1.-beta section from a
Alejandro Abdelnur created MAPREDUCE-5426:
-
Summary: MRAM fails to register to RM, AMRM token seems missing
Key: MAPREDUCE-5426
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5426
[
https://issues.apache.org/jira/browse/MAPREDUCE-4366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur resolved MAPREDUCE-4366.
---
Resolution: Fixed
Fix Version/s: 1.3.0
Hadoop Flags: Reviewed
to mention in the release notes the API changes and behavior changes that
YARN-918 and YARN-701 will bring into the next beta or GA release.
thx
On Wed, Jul 17, 2013 at 4:14 PM, Vinod Kumar Vavilapalli <
vino...@hortonworks.com> wrote:
>
> On Jul 17, 2013, at 1:04 PM, Alejandro Abdeln
Vinod,
Thanks for reviving this thread.
The current blockers are:
https://issues.apache.org/jira/issues/?jql=project%20in%20(hadoop%2C%20mapreduce%2C%20hdfs%2C%20yarn)%20and%20status%20in%20(open%2C%20'patch%20available')%20and%20priority%20%3D%20blocker%20and%20%22Target%20Version%2Fs%22%20%3D%
Alejandro Abdelnur created MAPREDUCE-5362:
-
Summary: clean up POM dependencies
Key: MAPREDUCE-5362
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5362
Project: Hadoop Map/Reduce
20, 2013, at 2:40 PM, Arun C Murthy wrote:
>
> > I think I've shared this before, but here you go again…
> >
> > http://s.apache.org/hadoop-2.1.0-beta-blockers
> >
> > At this point, HADOOP-9421 seems like the most important.
> >
> > thanks,
> >
Arun,
It seems there are still a few things to iron out before getting 2.1 out of
the door.
As RM for the release, would you mind sharing the current state of things
and your estimate on when it could happen?
Thanks.
On Wed, Jun 19, 2013 at 4:29 PM, Roman Shaposhnik wrote:
> On Tue, Jun 18,
Alejandro Abdelnur created MAPREDUCE-5333:
-
Summary: Add test that verifies MRAM works correctly when sending
requests with non-normalized capabilities
Key: MAPREDUCE-5333
URL: https://issues.apache.org
YARN-787.
>
> thanks,
> Arun
>
> On Jun 16, 2013, at 8:56 AM, Alejandro Abdelnur wrote:
>
> > Thanks Arun, I'll take care of committing YARN-752 and MAPREDUCE-5171
> > around noon today (SUN noon PST).
> >
> > What is your take on YARN-791 & MAPREDUCE
[
https://issues.apache.org/jira/browse/MAPREDUCE-5327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur resolved MAPREDUCE-5327.
---
Resolution: Invalid
MAPREDUCE-5310 stopped setting the MIN in the local
gt; > On Jun 15, 2013, at 8:19 AM, Alejandro Abdelnur wrote:
> >>
> >> Of the JIRAs in my laundry list for 2.1 the ones I would really want in
> are
> >> YARN-752, MAPREDUCE-5171 & YARN-787.
> >
> > I agree YARN-787 needs to go in ASAP & is a blo
I can take care of some
stuff if needed (while the monkeys sleep).
Thx
On Fri, Jun 14, 2013 at 9:56 PM, Alejandro Abdelnur wrote:
> Following is a revisited assessment of JIRAs I would like to get in the
> 2.1 release:
>
> From the 1st group I think all 3 should make.
>
> From t
Following is a revisited assessment of JIRAs I would like to get in the 2.1
release:
>From the 1st group I think all 3 should make.
>From the 2nd group I think YARN-791 should make it for sure and ideally
MAPREDUCE-5130.
>From the 3rd group, I don't think this JIRA will make it.
>From the 4th g
Arun
Forgot to make it explicit in previous email, I'll be happy to help so this
is done ASAP.
Please, let me know how you want to proceed
Thx
On Fri, Jun 14, 2013 at 2:02 PM, Alejandro Abdelnur wrote:
> Arun,
>
> This sounds great. Following is the list of JIRAs I'd l
Arun,
This sounds great. Following is the list of JIRAs I'd like to get in. Note
that the are ready or almost ready, my estimate is that they can be taken
care of in a couple of day.
Thanks.
* YARN-752: In AMRMClient, automatically add corresponding rack requests
for requested nodes
impact: beh
Alejandro Abdelnur created MAPREDUCE-5312:
-
Summary: TestRMNMInfo is failing
Key: MAPREDUCE-5312
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5312
Project: Hadoop Map/Reduce
Alejandro Abdelnur created MAPREDUCE-5311:
-
Summary: Remove slot millis computation logic and deprecate conters
Key: MAPREDUCE-5311
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5311
Alejandro Abdelnur created MAPREDUCE-5310:
-
Summary: MRAM should not normalize allocation request capabilities
Key: MAPREDUCE-5310
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5310
Alejandro Abdelnur created MAPREDUCE-5304:
-
Summary: mapreduce.Job killTask/failTask/getTaskCompletionEvents
methods have incompatible signature changes
Key: MAPREDUCE-5304
URL: https://issues.apache.org
+1 RC2. Verified MD5 & signature, checked CHANGES.txt files, built,
configured pseudo cluster, run a couple of sample jobs, tested HTTPFS.
On Mon, Jun 3, 2013 at 12:51 PM, Konstantin Boudnik wrote:
> I have rolled out release candidate (rc2) for hadoop-2.0.5-alpha.
>
> The difference between rc
think this
> is an issue. But I would be happy to fix it if this seems to be a problem.
>
> Thanks,
> Cos
>
> On Sat, Jun 01, 2013 at 08:04PM, Alejandro Abdelnur wrote:
>> On RC1, verified MD5 & signature, built, configured pseudo cluster, run a
>> couple of sample
; releases 2.0.4-alpha. As for the top-level readme file - sorry I wasn't
> > aware
> > > about them. As for the binary: I am pretty sure we are only releasing
> > source
> > > code, but I will put binaries into the rc1 respin.
> > >
> > > I will re
Verified MD5 & signature, built, configured pseudo cluster, run a couple of
sample jobs, tested HTTPFS.
Still, something seems odd.
The HDFS CHANGES.txt has the following entry under 2.0.5-alpha:
HDFS-4646. createNNProxyWithClientProtocol ignores configured timeout
value (Jagane Sundar via cos
Cos, just to be clear, this is happening SAT JUN01 1PM-2PM PST, not now
(FRI MAY31 1PM PST). Correct?
Thx
On Fri, May 31, 2013 at 12:45 PM, Konstantin Boudnik wrote:
> Guys,
>
> I will be performing some changes wrt to moving 2.0.4.1 release candidate
> to
> 2.0.5 space. As outline below by Ale
Konstantin, Cos,
As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
housekeeping as you work the new RC.
* rename the svn branch
* update the versions in the POMs
* update the CHANGES.txt in trunk, branch-2 and the release branch
* change the current 2.0.5 version in JIRA to 2.1.0
On the version number we use, if it is greater than 2.0.4, I really don't
care. Though I think Konstantin argument that branch-2 is publishing as
2.0.5-SNAPSHOT has some ground (still, it could be argued that they are DEV
JARs so they can be in flux).
On the changes that went into this RC, they a
+1, verified MD5 and signature. Did a full build, started pseudo cluster,
run a few MR jobs, verified httpfs works.
Thanks.
On Tue, May 28, 2013 at 9:00 AM, Thomas Graves wrote:
>
> I've created a release candidate (RC0) for hadoop-0.23.8 that I would like
> to release.
>
> This release is a su
+1, verified MD5 and signature. Did a full build, started pseudo cluster,
run a few MR jobs, verified httpfs works.
Thanks.
On Sat, May 25, 2013 at 10:01 AM, Sangjin Lee wrote:
> +1 (non-binding)
>
> Thanks,
> Sangjin
>
>
> On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik
> wrote:
>
> > Al
be fine. I presume common and
> > hdfs too.
> > >
> > > MR clearly has issues. Have to manually fix it. Will do something
> > tomorrow first thing.
> > >
> > > Thanks,
> > > +Vinod Kumar Vavilapalli
> > >
> > > On Apr 1, 2013,
Alejandro Abdelnur created MAPREDUCE-5123:
-
Summary: Reimplement things
Key: MAPREDUCE-5123
URL: https://issues.apache.org/jira/browse/MAPREDUCE-5123
Project: Hadoop Map/Reduce
Issue
1 - 100 of 216 matches
Mail list logo
