+1
On Wed, Dec 6, 2023 at 9:03 AM Chao Sun wrote:
> +1
>
> On Wed, Dec 6, 2023 at 8:39 AM Akira Ajisaka wrote:
> >
> > +1
> >
> >
> >
> > On Wed, Dec 6, 2023 at 1:10 PM Xiaoqiao He wrote:
> >
> > > Dear Hadoop devs,
> > >
> > > Given the feedback from the discussion thread [1], I'd like to sta
I am pleased to announce that Simbarashe Dzinamarira has been elected as a
committer on the Apache Hadoop project.
We appreciate all of Simbarashe's work, and look forward to his continued
contributions.
Congratulations and welcome !
Best Regards,
Inigo Goiri
(On behalf of the Apache Hadoop PMC)
I would also vote for targeting 3.4 and have a long term version of Java
there.
On Tue, Mar 28, 2023 at 11:52 AM Igor Dvorzhak
wrote:
> +1 to re-focusing on 3.4 branch and upgrading it to Java 11/17, instead of
> making potentially breaking changes to 3.3.
>
> On Tue, Mar 28, 2023 at 11:17 AM Ch
Now that we are using mostly GitHub PRs for the reviews and we have decent
integration for the builds etc there, I was wondering about code coverage
and reporting.
Is code coverage setup at all?
Does this come from the INFRA team?
What would it take to enable it otherwise?
+1 (Binding)
Deployed a cluster on Azure VMs with:
* 3 VMs with HDFS Namenodes and Routers
* 2 VMs with YARN Resource Managers
* 5 VMs with HDFS Datanodes and Node Managers
Tests:
* Executed Tergagen+Terasort+Teravalidate.
* Executed wordcount.
* Browsed through the Web UI.
On Fri, Jul 10, 202
I wouldn't go for #3 and always require a JIRA for a PR.
In general, I think we should state the best practices for using GitHub PRs.
There were some guidelines but they were kind of open
For example, adding always a link to the JIRA to the description.
I think PRs can have a template as a start.
+1
On Wed, Jul 17, 2019 at 4:17 AM Steve Loughran
wrote:
> +1 for squash and merge, with whoever does the merge adding the full commit
> message for the logs, with JIRA, contributor(s) etc
>
> One limit of the github process is that the author of the commit becomes
> whoever hit the squash butto
+1 from my side.
I also added a comment to HDFS-14268 explaining the reasons to modify
ECBlockGroupStats.
We can follow up into possible changes there if needed.
On Mon, Jun 10, 2019 at 8:10 AM Arpit Agarwal
wrote:
> I scanned the merge payload for changes to non-RBF code. The changes are
> mi
Thank you Brahma for pushing this.
As you mentioned, we have already taken most of the changes into production.
I want to highlight that the main contribution is the addition of security.
We have been able to test this at a smaller scale (~500 servers and 4
subclusters) and the performance is grea
Syncing the branch to trunk should be a fairly standard task.
Is there a way to do this without rebasing and forcing the push?
As far as I know this has been the standard for other branches and I don't
know of any alternative.
We should clarify the process as having to get PMC consensus to rebase a
Thanks Hexiaoqiao for starting the vote.
As I said in the JIRA, I prefer Approach A.
I wanted to bring a broader audience as this has changes in RBF, HDFS and
Commons.
I think adding a new optional field to the RPC header should be lightweight
enough.
The idea of passing a proxied client is alread
+1
On Tue, Feb 5, 2019 at 8:22 AM Masatake Iwasaki
wrote:
> +1
>
> Masatake Iwasaki
>
> On 2/4/19 18:13, Jonathan Hung wrote:
> > Hello,
> >
> > Starting a vote based on the discuss thread [1] for moving branch-2
> > precommit/nightly test builds to openjdk8. After this change, the test
> > phas
+1 (binding)
- Deployed a cluster with 3 NNs, 3 RMs and 1 DN/NM on Azure
- Tested the Active probe for the Load Balancer in front of the NNs and the
RMs
- Checked the NN, RBF, and RM Web UIs
- Executed a TeraGen, TeraSort and TeraValidate
- Executed a YARN service with a TensorFlow app on Docker
+1 (non-binding)
- Deployed a cluster with 3 NNs, 3 RMs and 1 DN/NM on Azure
- Tested the Active probe for the Load Balancer in front of the NNs and the
RMs
- Checked the NN, RBF, and RM Web UIs
- Executed a wordcount, TeraGen, TeraSort and TeraValidate
- Executed a YARN service with a TensorFlow
+1 (non-binding)
- Installed a full cluster from the tgz on Azure:
-- 2 NNs in HA.
-- 2 RMs in HA.
-- 2 Routers for RBF.
-- One worker with NM and DN.
- Verified Web UIs.
- Executed Teragen/Terasort/Teravalidate through RBF.
- Scaled up the cluster from 1 to 10 workers and executed the jobs again.
+1 (non binding)
* Deployed with 4 subclusters with HDFS Router-based federation.
* Executed DistCp across subclusters through the Router
* Checked documentation and tgz
On Tue, Apr 3, 2018 at 4:25 PM, Vinod Kumar Vavilapalli
wrote:
> We vote on the source code. The binaries are convenience art
Thank you very much Allen for making the Windows build work again.
We are going through the unit tests and fixing them for Windows (as you
said mostly paths).
We got a couple related patches in already; this will help us track
progress.
On Thu, Mar 15, 2018 at 10:15 AM, Allen Wittenauer wrote:
>
+1
I have been reviewing some of the latest patches.
I skimmed through the patch in HDFS-9806 and it looks good.
In addition, we have ported it to 2.7.1 (minor differences to what would be
merged).
It has been running in our test cluster for a couple months.
All the issues we have been finding are
+1 (non-binding)
I tested it in a deployment with 24 nodes across 8 subclusters.
Tested a few jobs reading and writing data through HDFS Router-based
federation.
However, jobs failed to run when setting RBF as the default filesystem
because after MAPREDUCE-6954, it tries to invoke setErasureCoding
+1 (non-binding)
Deployed in a cluster with 48 nodes and 8 subclusters:
- YARN federation
- HDFS Router-based federation
- Yarn UI 2
Executed a few Pi job using both HDFS and YARN federation.
Everything worked correctly.
The YARN UI 2 showed the jobs, etc.
On Wed, Nov 15, 2017 at 2:05
new umbrella for the second phase.
Thanks for the votes!
On Tue, Oct 3, 2017 at 9:50 AM, Brahma Reddy Battula
wrote:
> Thanks Inigo.
>
> +1 (binding)
>
> Nice feature.Involved in reviewing some jiras.
>
> On Sat, 30 Sep 2017 at 12:29 AM, Iñigo Goiri wrote:
>
> &g
Hi all,
Given that 3.0-beta1 is already cut, I’d like to call a vote for merging
Router-Based Federation (HDFS-10467) to trunk and branch-3.
The vote will run for 7 days as usual.
We started the discussion about merging HDFS-10467 a few weeks ago [1] and
got good feedback which we’ve incorpora
Hi Subru,
We are also discussing the merge of HDFS-10467 (Router-based federation)
and we would like to target 2.9 to do a full release together with YARN
federation.
Chris Douglas already arranged the integration into trunk for 3.0.0 GA.
Regarding the points to cover:
1. API compatibility: we jus
/app1 in subcluster0, we mount it in
/data/app1 in the federated namespace.
Additionally, we are testing a Rebalancer that takes into consideration the
size of the mount table (based on the USENIX ATC paper).
I can extend the documentation in HDFS-12381.
On Thu, Aug 31, 2017 at 4:52 PM, Iñigo
Agreed on this not being the cleanest..
Just filed it this morning: HDFS-12384.
On Thu, Aug 31, 2017 at 4:36 PM, Andrew Wang
wrote:
> v) mvn install (and package) is failing with following error
>>
>> [INFO] Adding ignore: *
>> [WARNING] Rule 1: org.apache.maven.plugins.enforcer.BanDuplicateC
> [1] https://issues.apache.org/jira/browse/HADOOP-14741
> [2] git diff --diff-filter=M $(git merge-base apache/HDFS-10467
> apache/trunk)..apache/HDFS-10467
>
> > On Thu, Aug 24, 2017 at 1:39 PM, Chris Douglas
> wrote:
> >>
> >> I'd definitely support merging
Hi all,
We would like to open a discussion on merging the Router-based Federation
feature to trunk.
Last week, there was a thread about which branches would go into 3.0 and
given that YARN federation is going, this might be a good time for this to
be merged too.
We have been running "Router-b
27 matches
Mail list logo
