; ,
"yarn-...@hadoop.apache.org" ,
"common-...@hadoop.apache.org" ,
"mapreduce-...@hadoop.apache.org" , Vinod
Kumar Vavilapalli
Subject: Re: Hadoop 3.1.0 release discussion
Thanks for the update.
On Tue, Jan 30, 2018 at 4:51 PM, Gangumalla, Uma
mailto:uma.ganguma...@i
Thanks, I saw HDFS-13050 has been resolved 4 hours ago, I don't see any
other blockers under HDFS-10285. I think you guys should be able to start
voting thread in time for merging to trunk.
- Wangda
On Mon, Jan 29, 2018 at 3:12 AM, Gangumalla, Uma
wrote:
Ozone. Given the discussion on HDFS-7240. Looks challenging
to be done before Jan 2018.
* (Varun V) YARN-5673: container-executor write. Given security refactoring of
c-e (YARN-6623) is already landed, IMHO other stuff may be moved to 3.2.
Thanks,
Wangda
On Mon, Jan 22, 2018 at 1:49 PM, Ganguma
Sure, Wangda.
Regards,
Uma
On 1/18/18, 10:19 AM, "Wangda Tan" wrote:
Thanks Uma,
Could you update this thread once the merge vote started?
Best,
Wangda
On Wed, Jan 17, 2018 at 4:30 PM, Gangumalla, Uma
wrote:
> HI Wangda,
>
HI Wangda,
Thank you for the head-up mail.
We are in the branch (HDFS-10285) and trying to push the tasks sooner before
the deadline.
Regards,
Uma
On 1/17/18, 11:35 AM, "Wangda Tan" wrote:
Hi All,
Since we're fast approaching previously proposed feature freeze date (Jan
30,
Here is my +1(binding) too.
Sorry for late vote.
Verified signatures of the source tarball.
built from source.
set up a 2-node test cluster.
Tested via HDFS commands and java API – Written bunch of files and read back.
Ran basic MR job
Thanks Andrew and others for the hard work for getting Hado
Plan looks good to me.
+1
Regards,
Uma
On 8/25/17, 10:36 AM, "Andrew Wang" wrote:
>Hi folks,
>
>With 3.0.0-beta1 fast approaching, I wanted to go over the proposed
>branching strategy.
>
>In the early 2.x days, moving trunk immediately to 3.0.0 was a mistake.
>branch-2 and trunk were virtually
Hi Andrew,
>Great to hear. It'd be nice to define which use cases are met by the current
>version of SPS, and which will be handled after the merge.
After the discussions in JIRA, we planned to support recursive API as well. The
primary use cases we planned was for Hbase. Please check next point
ike they would), then we can cut branch-3
first, or wait to merge until after these tasks are finished.
Best,
Andrew
On Mon, Jul 24, 2017 at 11:35 PM, Gangumalla, Uma
mailto:uma.ganguma...@intel.com>> wrote:
Dear All,
I would like to propose Storage Policy Satisfier(SPS) feature merge into
Dear All,
I would like to propose Storage Policy Satisfier(SPS) feature merge into trunk.
We have been working on this feature from last several months. This feature
received the contributions from different companies. All of the feature
development happened smoothly and collaboratively in JIRA
+1 (binding).
Overall it¹s a great effort, Andrew. Thank you for putting all the energy.
Downloaded and built.
Ran some sample jobs.
I would love to see all this efforts will lead to get the GA from Hadoop
3.X soon.
Regards,
Uma
On 8/30/16, 8:51 AM, "Andrew Wang" wrote:
>Hi all,
>
>Thanks t
For Huawei, Vinay/Brahma should know about their usage. I think after QJM
stabilized and ready they also adopted to QJM is what I know, but they
should know more than me as I left that employer while ago.
If no one is using it, It is ok to remove.
Regards,
Uma
On 7/27/16, 9:49 PM, "Rakesh Radhak
On 6/13/16, 12:41 PM, "Anu Engineer" wrote:
>Hi Colin,
>
>>Even if everyone used branches for all development, person X might merge
>>their branch before person Y, forcing person Y to do a rebase or merge.
>>It is not the presence of absence of branches that causes the need to
>>merge or rebase
+1
Regards,
Uma
On 5/10/16, 2:24 PM, "Andrew Wang" wrote:
>+1
>
>On Tue, May 10, 2016 at 12:36 PM, Ravi Prakash
>wrote:
>
>> +1. Thanks for driving this Akira
>>
>> On Tue, May 10, 2016 at 10:25 AM, Tsuyoshi Ozawa
>>wrote:
>>
>> > > Before cutting 3.0.0-alpha RC, I'd like to drop JDK7 support
Yes. I think starting 3.0 release with alpha is good idea. So it would get
some time to reach the beta or GA.
+1 for the plan.
For the compatibility purposes and as current stable versions, we should
continue 2.x releases anyway.
Thanks Andrew for starting the thread.
Regards,
Uma
On 2/18/16,
To: common-...@hadoop.apache.org
>Cc: hdfs-dev@hadoop.apache.org
>Subject: Re: Hadoop encryption module as Apache Chimera incubator project
>
>On Thu, Feb 4, 2016 at 12:06 PM, Gangumalla, Uma
> wrote:
>
>> [UMA] Ok. Great. You are right. I have cc¹ed to hadoop common. (You
>&g
rocessing from MapReduce? Evolving some of
>this code to a common library with few/no dependencies would be generally
>useful. As a subproject, it could have a broader scope that could evolve
>into a viable TLP. If the encryption libraries are the only ones you're
>interested in pulli
Thanks Vinod. +1 for 2.8 release start.
Regards,
Uma
On 2/3/16, 3:53 PM, "Vinod Kumar Vavilapalli" wrote:
>Seems like all the features listed in the Roadmap wiki are in. I¹m going
>to try cutting an RC this weekend for a first/non-stable release off of
>branch-2.8.
>
>Let me know if anyone has
Thanks guys for the opinions. Below are my responses for some questions or
thoughts.
On 2/3/16, 12:07 AM, "Chen, Haifeng" wrote:
>Thanks Chris and Colin for your opinions.
>
>>> [Chris] If Chimera is not successful as an independent project or
>>>stalls, Hadoop and/or Spark and/or $project will
Thanks for the inputs Owen.
On 1/27/16, 11:31 AM, "Owen O'Malley" wrote:
>On Wed, Jan 27, 2016 at 9:59 AM, Gangumalla, Uma
>
>wrote:
>
>> I think Chimera goal is to enhance even for other use cases.
>
>
>Naturally.
>
>
>> For Hadoop, CTR mod
I think Chimera goal is to enhance even for other use cases. For Hadoop,
CTR mode should be enough today, but when we want to support other modes
for other users(ex:While a lot of encryption such as network encryption or
data transfer encryption over the wire doesn't necessarily CTR, other
modes su
ce! My question is, could we consider to
>>adopt the approach for libhadoop.so library? It might be worth to discuss
>>because, we're bundling more and more things into the library (recently
>>we just put Intel ISA-L support into it), and such things may be desired
>>for suc
another
>bug like HADOOP-11343, we'll first need to get the fix into Chimera, have
>a
>new Chimera release, then bump Hadoop's Chimera dependency. This also
>relates to the previous point, it's easier to do this dependency bump if
>Chimera is a separate JAR.
>
>Best
Hi Devs,
Some of our Hadoop developers working with Spark community to implement the
shuffle encryption. While implementing that, they realized some/most of the
code in Hadoop encryption code and their implemention code have to be
duplicated. This leads to an idea to create separate library,
e also thinks that feature is ready to goto branch-2 as
>>>well?
>>>
>>> Its > 2 weeks EC landed on trunk. IMo Looks Its quite stable since
>>>then and
>>> ready to go in branch-2.
>>>
>>> -Vinay
>>> On Oct 6, 2015 12:51 AM
gt; > >
>> > > > +1
>> > > >
>> > > > I've been involved in both development and review on the branch,
>>and
>> I
>> > > > believe it's now ready to get merged into trunk. Many thanks to
>>all
>> > &
+1
Great addition to HDFS. Thanks all contributors for the nice work.
Regards,
Uma
On 9/22/15, 3:40 PM, "Zhe Zhang" wrote:
>Hi,
>
>I'd like to propose a vote to merge the HDFS-7285 feature branch back to
>trunk. Since November 2014 we have been designing and developing this
>feature under the
Hi,
HDFS does store the data how you writing to it. It will not organize the data.
HDFS has flexibility I terms of placements.
If you want to write in this fashion bunch of blocks should be allocated once
and client should write all of them based on you portion. Which is sounding
something simi
+1
Regards,
Uma
-Original Message-
From: Karthik Kambatla [mailto:ka...@cloudera.com]
Sent: Saturday, August 09, 2014 8:27 AM
To: common-...@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
yarn-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org
Subject: [VOTE] Migration from subversi
+1
Regards,
Uma
-Original Message-
From: Arun C Murthy [mailto:a...@hortonworks.com]
Sent: Tuesday, June 24, 2014 2:24 PM
To: common-...@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
yarn-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org
Subject: [VOTE] Change by-laws on release v
: [DISCUSS] Change by-laws on release votes: 5 days instead of 7
Uma,
Voting periods are defined in *minimum* terms, so it already covers what you'd
like to see i.e. the vote can continue longer.
thanks,
Arun
> On Jun 21, 2014, at 2:19 AM, "Gangumalla, Uma"
> wrote:
>
> H
How about proposing vote for 5days and give chance to RM for extending vote for
2more days( total to 7days) if the rc did not receive enough vote within 5days?
If a rc received enough votes in 5days, RM can close vote.
I can see an advantage of 7days voting is, that will cover all the week and
w
rt etc
Regards,
Uma
-Original Message-
From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
Sent: Wednesday, May 21, 2014 8:06 PM
To: hdfs-dev@hadoop.apache.org
Subject: RE: [Vote] Merge The HDFS XAttrs Feature Branch (HDFS-2006) to Trunk
Thanks a lot, for the great work on branch and supp
Yes. Suresh.
I have merged HDFS-2006 (Extended Attributes) to branch-2. So, that it will be
included in 2.5 release.
Regards,
Uma
-Original Message-
From: Suresh Srinivas [mailto:sur...@hortonworks.com]
Sent: Tuesday, June 10, 2014 10:15 PM
To: mapreduce-...@hadoop.apache.org
Cc: commo
Hi,
I have done the merge. Please proceed with your commits.
Regards,
Uma
-Original Message-
From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
Sent: Wednesday, May 21, 2014 7:12 PM
To: hdfs-dev@hadoop.apache.org
Subject: Please hold off the commits into HDFS and Common for some
Thanks a lot, for the great work on branch and support.
I have just completed the merge of HDFS Extended attributes branch(HDFS-2006)
to trunk.
Regards,
Uma
-Original Message-
From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
Sent: Wednesday, May 21, 2014 6:38 PM
To: hdfs-dev
Hi Committers,
Please hold the commits to trunk for some time until I notify as I am merging
the HDFS-2006 branch into trunk.
Regards,
Uma
Thanks a lot for participating in this vote.
With 4 +1's( from Me, Andrew Wang, Chris and Colin) and no -1, the vote has
passed for the merge.
I will do the merge shortly to trunk.
Regards,
Uma
-Original Message-
From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
Hello HDFS Devs,
I would like to call for a vote to merge the HDFS Extended Attributes
(XAttrs) feature from the HDFS-2006 branch to the trunk.
XAttrs are already widely supported on many operating systems, including
Linux, Windows, and Mac OS. This will allow storing attributes for HDFS
fil
39 matches
Mail list logo
