Suresh,
While you are at it, can you take a look at MAPREDUCE-4049 too ? It has been
sitting there too long.
- Milind
On Jul 3, 2012, at 9:24 AM, Suresh Srinivas wrote:
> Madhu,
>
> I will take a look at the jiras and commit them in next couple of days.
>
> Regards,
> Suresh
>
> On Tue, Jul
That's great Junping.
Hoping to see this in trunk / hadoop 2.0 and hadoop 1.1 soon.
- milind
On Jun 4, 2012, at 8:48 AM, Jun Ping Du wrote:
> Hello Folks,
> I just filed a Umbrella jira today to address current NetworkTopology
> issue that binding strictly to three tier network. The motiv
Ralph,
Do you have a home directory on HDFS ?
The job files are moved under your HDFS home directory, in a .staging
subdir.
In any case, not flagging it as an error, seems to be a genuine yarn bug.
- milind
---
Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email
Great !
Thanks @atm,
- milind
On 4/3/12 3:21 PM, "Aaron T. Myers" wrote:
>If that's the case then there doesn't seem to be any question here. The
>feature is in trunk, and an implementation could be done for an older
>release branch that would be compatible with that branch. Sure, the code
>to
To my knowledge, shuffle is already pluggable in 0.23 onwards, as long as
it is used only by mapreduce framework.
That's why Avner says : "In parallel, I'll try to *learn what exists* in
0.23". (Emphasize my own.)
That's why I was wondering about the insistence of committing to trunk
first.
- Mi
Thanks ATM.
I guess the "*may*" emphasis confused me.
Just to get some more clarity:
What would be guideline for a new feature, such as
https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
compatibility for 1.x, but is not relevant to trunk, because the codebases
have completely
Arun,
I am even more confused now than I was before:
Here you say:
> Essentially 'trunk' is where incompatible changes *may* be committed (in
>future). We should allow for that.
On another thread, responding to Avner (re: MAPREDUCE-4049?) you say,
> We do expect 'new features' to make it to t
Ronald,
Please take a look at https://issues.apache.org/jira/browse/HADOOP-7147,
and https://issues.apache.org/jira/browse/HADOOP-7824
- milind
On 12/1/11 5:31 PM, "Ronald Petty" wrote:
>Alejandro,
>
>I suppose I will give it a go since that is the computer I have. I tried
>searching on JIRA
Great ! Works for me ! Thanks Ralph.
- Milind
---
Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email are those of the author, and
do not necessarily represent the views of any organization, past or
present, the author might be affiliated with.)
On 11/23/11 5:13
Ralph,
Yes, I have completed the first step, although I would really like that
code to be part of the MPI Application Master (Chris Douglas suggested a
way to do this at ApacheCon).
Regarding the remaining steps, I have been following discussions on the
open mpi mailing lists, and reading code fo
Hi Ralph,
I spoke with Jeff Squyres at SC11, and updated him on the status of my
OpenMPI port on Hadoop Yarn.
To update everyone, I have OpenMPI examples running on #Yarn, although it
requires some code cleanup and refactoring, however that can be done as a
later step.
Currently, the MPI proces
Last year, Rini Kaushik and I authored a paper "GreenHDFS: Towards An
Energy-Conserving,
Storage-Efficient, Hybrid Hadoop Compute Cluster" at HotPower'10 (PDF here:
http://www.usenix.org/event/hotpower10/tech/full_papers/Kaushik.pdf) that
analyzed "hotness" of files based on real namenode audit logs
Replication policy in HDFS is pluggable, since hadoop 0.21:
https://issues.apache.org/jira/browse/HDFS-385
- Milind
On 10/10/11 10:26 PM, "Uma Maheswara Rao G 72686"
wrote:
>To get the best performance from Hadoop, we can configure network
>topology.
>Based on that, it will apply RackAwarene
>
>
>
>These are all good ideas. The other trick -which has been discussed
>recently in the context of the Platform Scheduler- is to run HDFS across
>all nodes, but switch the workload of the cluster between Hadoop jobs
>(MR, Graph, Hamster), and other work (Grid jobs). That way the
>filesystem is
For those who are not aware of 6-year old history :-), Sameer, Owen and I
made a trip to Wisconsin, Madison to meet with Miron Livny, who built
Condor, exploring how matchmaking could be used with MapReduce
(pre-hadoop) in October 2005. (We believed it could be used for
locality-aware scheduling.)
>
>
>
>The problem is that the 0.20.2xx releases are neither a superset or subset
>of the 0.21 release. In many ways, the 0.20.2xx.y releases would be better
>named as 1.x.y.
This confused me totally. Is the thinking to make 0.20.2xx.y as 1.x.y or
is it 0.23.x which will become 1.x.y ?
- milind
Aha!
In that case, is the local test-patch success sufficient for patches on
branches ?
- milind
On 8/5/11 3:38 PM, "Giridharan Kesavan" wrote:
>Milind,
>
>patch testing usually happens only on trunk
>
>
>thanks,
>Giri
>
>On Fri, Aug 5, 2011 at 3:11 PM, wrote:
>
>> Hi folks,
>>
>> Now that th
Hi folks,
Now that the build machines are available again, I tried resubmitting a patch
to https://issues.apache.org/jira/browse/MAPREDUCE-2767. However, it looks like
it is not being picked up by CI.
Is 0.22 branch excluded from hadoop CI ?
* Milind
---
Milind Bhandarkar
Greenplum Labs,
Somehow I remember that the 0.20.203.0 vote was carried out on general@
Here is a message from the archive:
http://mail-archives.apache.org/mod_mbox/hadoop-general/201105.mbox/browser
- milind
---
Milind Bhandarkar
-Original Message-
From: Arun C Murthy [mailto:a...@hortonworks.com]
I saw @jeric14's tweet about 0.20.204 vote last night, and was about to reply,
because I could not see any vote on the general@ mailing list.
Yes, toy are right @atm, the vote should be on general@.
- milind
---
Milind Bhandarkar
-Original Message-
From: Aaron T. Myers [mailto:a...@clo
20 matches
Mail list logo
