> I usually use PR comments to discuss about the patch submitted.
My concern is that still leaves multiple places to look in order to get a full
picture of an issue.
-Eric
On Wednesday, July 14, 2021, 7:07:30 PM CDT, Masatake Iwasaki
wrote:
> - recently, JIRA became some sort of a "numb
+1 for a review of the backlog!-Eric
On Wednesday, July 14, 2021, 10:02:39 AM CDT, Wei-Chiu Chuang
wrote:
We have more than 400 open PRs. I would be happy to find a way to reduce
that number to a more manageable size.
Otherwise it just becomes another JIRA where issues are filed and sunk
Ahmed has pinpointed my main concern with both JIRA and PR for the same issue.I
often go back to older issues to try to understand the reasons behind the
designs.It is somewhat cumbersome to try and follow discussions between JIRA
and PRs.Thanks,-Eric
On Wednesday, July 14, 2021, 9:50:47 A
+1 (binding)
Eric
On Tuesday, June 1, 2021, 5:29:49 AM CDT, Wei-Chiu Chuang
wrote:
Hi community,
This is the release candidate RC3 of Apache Hadoop 3.3.1 line. All blocker
issues have been resolved [1] again.
There are 2 additional issues resolved for RC3:
* Revert "MAPREDUCE-7303. Fi
+1 (binding)
-Eric
On Thursday, June 3, 2021, 1:14:51 AM CDT, Akira Ajisaka
wrote:
Dear Hadoop developers,
Given the feedback from the discussion thread [1], I'd like to start
an official vote
thread for the community to vote and start the 3.1 EOL process.
What this entails:
(1) an o
It is okay to go ahead and backport as long as there are no major refactoring
necessary.Minor conflict fixes should be fine.-Eric
On Tuesday, June 1, 2021, 11:43:44 PM CDT, Wei-Chiu Chuang
wrote:
I'm curious about the GitHub PR conventions we use today... say I want to
backport a commit fro
I would be fine with a discussion and vote on relaxing some checkstyle
restrictions.
Regarding line length, my personal preference is to leave it at 80, but 80 is
arbitrary and I would not oppose 100 if that's what people want.
Another one that I think should be relaxed is the limit on number o
Congratulations Hui Fei!
On Wednesday, September 23, 2020, 1:07:11 PM CDT, Wei-Chiu Chuang
wrote:
I am pleased to announce that Hui Fei has accepted the invitation to become
a Hadoop committer.
He started contributing to the project in October 2016. Over the past 4
years he has contributed a l
two upgrade approaches from the community documentation:
> > express upgrade and rolling upgrade. Rolling upgrade was selected.
> >
> > Yahoo Japan was trying out from hadoop-2.6 to hadop-3.2.1
> >
> > https://techblog.yahoo.co.jp/entry/20191206786320/
> >
&g
and rolling upgrade. Rolling upgrade was selected.
Yahoo Japan was trying out from hadoop-2.6 to hadop-3.2.1
https://techblog.yahoo.co.jp/entry/20191206786320/
On Wed, Aug 26, 2020 at 6:56 PM epa...@apache.org wrote:
> Hello. Just a reminder that today I would like to invite you all
Hello. Just a reminder that today I would like to invite you all to discuss your
experiences migrating from Hadoop 2 to Hadoop 3.
-Eric
On Monday, August 24, 2020, 1:58:37 PM CDT, epa...@apache.org
wrote:
Hello everyone!
We are considering migrating to Hadoop 3, and we would be very
Hello everyone!
We are considering migrating to Hadoop 3, and we would be very interested to
hear about your experiences. If you have migrated from Hadoop 2 to Hadoop 3
and can provide insights, please kindly consider attending the following:
Date: Wednesday, Aug 26, 2020
Time: 10:00 A.M. PDT / 1
year now in parallel with a legacy 2.7.3 cluster, and have clients from
both
communicating with HDFS on the other cluster frequently.As usual, YMMV, but we
haven't
encountered any serious problems.
- Craig Condit
____
From: epa...@apache.org
Sent: Monday, August
Hello,
We are investigating upgrading to 3.x, but we are very concerned about the
differences in the HDFS features, interfaces, etc. between 2.10 and 3.3+. Our
requirements are to not have any cluster downtime and to allow 2.10 HDFS
clients to communicate with 3.x clusters and 3.x HDFS clients
I am pleased to announce that Jim Brennan has accepted the invitation to become
a Hadoop committer focusing on the YARN space.
Please reach out to Jim and welcome him in his new role.
Congratulations, Jim! Well-deserved!
-Eric Payne
-
There was some discussion on https://issues.apache.org/jira/browse/YARN-9052
about concerns surrounding the costs/benefits of code cleanup JIRAs. This email
is to get the discussion going within a wider audience.
The positive points for code cleanup JIRAs:
- Clean up tech debt
- Make code more rea
ly need to, by
> recreating branch-2. But this proposal would reduce a lot of confusion IMO.
>
> Jonathan Hung
>
>
> On Fri, Nov 15, 2019 at 11:41 AM epa...@apache.org
> wrote:
>
> > Thanks Jonathan for opening the discussion.
> >
> > I am not in favor of
Thanks Jonathan for opening the discussion.
I am not in favor of this proposal. 2.10 was very recently released, and moving
to 2.10 will take some time for the community. It seems premature to make a
decision at this point that there will never be a need for a 2.11 release.
-Eric
On Thursday
Compatibility testing has gone well for me.
- In a 4-node cluster, I ran YARN rolling upgrade tests between 2.8.5 and
2.10.0
- In a 4-node cluster, I ran YARN rolling upgrade tests between 2.10.0 and trunk
- With one 4-node cluster running 2.10.0 and one 4-node cluster running trunk,
I ran a wo
d RC0 is HDFS-14667. If RC1 looks good to you then it'd
be great to get your testing results on that thread.
Jonathan Hung
On Mon, Oct 28, 2019 at 1:06 PM epa...@apache.org wrote:
> Compatibility testing has gone well for me.
>
> - In a 4-node cluster, I ran YARN rolling upgrade
Compatibility testing has gone well for me.
- In a 4-node cluster, I ran YARN rolling upgrade tests between 2.8.5 and 2.10.0
- In a 4-node cluster, I ran YARN rolling upgrade tests between 2.10.0 and trunk
- With one 4-node cluster running 2.10.0 and one 4-node cluster running trunk,
I ran a word
mapreduce.application.framework.path to run your MR jobs? If not, this seems
like expected behavior if AM and tasks get launched on different NMs with
different locally installed hadoop versions?
Jonathan Hung
On Sat, Oct 26, 2019 at 8:55 AM epa...@apache.org wrote:
I ran a few compatibility tests between
I ran a few compatibility tests between 2.10.0 and 3.3.0 (trunk)
Unfortunately, I ran into the following problem:
Running with 2.10 RM and 3.3.0 (trunk) NM fails attempts with the following
error:
2019-10-26 15:44:06,885 WARN [main] org.apache.hadoop.mapred.YarnChild:
Exception running child :
Hi Jonathan,
Thanks very much for all of your work on this release.
I have a concern about cross-queue (inter-queue) preemption in 2.10.
In 2.8, on a 6 node pseudo-cluster, preempting from one queue to meet the needs
of another queue seems to work as expected. However, 2.10 in the same
pseudo-
+1 (binding)
Thanks Zhankun for all of your hard work on this release.
I downloaded and built the source and ran it on an insecure multi-node pseudo
cluster.
I performed various YARN manual tests, including creating custom resources,
creating queue submission ACLs, and queue refreshes.
One
Yes, I think it must have been. branch-3 is not needed right now. I would be
in favor of its removal, since it is confusing for committers.
Thanks,-Eric
On Tuesday, August 27, 2019, 6:24:09 PM CDT, Wei-Chiu Chuang
wrote:
I just realized there is a branch-3 in the Hadoop repo. Was thi
Let's go with bi-weekly (every 2 weeks). Sometimes this gives us 3 sync-ups in
one month, which I think is fine.
-Eric Payne
On Wednesday, August 21, 2019, 5:01:52 AM CDT, Wangda Tan
wrote:
>
> For folks in other US time zones: how about 11am PDT, is it better or 10am
> PDT will be better? I
Hi Wangda,
Thank you for continuing to keep us moving forward and refining these vital
sync-ups.
> 3) Update the US [YARN/MapReduce] sync up time from 9AM to 10AM PDT.
That puts it at noon central time, which is during our lunch hour. However, I
am +1 for this if we are able to allow greater pa
28 matches
Mail list logo
