+1 (Binding), I tried to use YARN service assembly before to run different
kinds of jobs (for example, distributed Tensorflow), it is really easy for
end user to run jobs on YARN.
Thanks to the whole team for the great job!
Best,
Wangda
On Fri, Sep 1, 2017 at 3:33 PM, Gour Saha wrote:
> +1 (n
+1 (non-binding)
On 9/1/17, 11:58 AM, "Billie Rinaldi" wrote:
>+1 (non-binding)
>
>On Thu, Aug 31, 2017 at 8:33 PM, Jian He wrote:
>
>> Hi All,
>>
>> I would like to call a vote for merging yarn-native-services to trunk.
>>The
>> vote will run for 7 days as usual.
>>
>> At a high level, the fol
https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+3+release+status+updates
2017-09-01
We're two weeks out from beta1, focus is on blocker burndown.
Highlights:
- S3Guard merged!
- TSv2 alpha2 merged!
- branch-3.0 has been cut after discussion on dev lists.
Red flags:
- 10
This issue (HADOOP-14439) is out of my radar given it is marked as Minor
priority. If my understanding is correct, here is a trade-off between security
and backward compatibility. IMO, priority of security is generally higher than
backward compatibility especially 2.8.0 is still non-production r
Hi folks,
I've proceeded with the plan from our earlier thread and cut branch-3.0.
The branches and maven versions are now set as follows:
trunk: 3.1.0-SNAPSHOT
branch-3.0: 3.0.0-beta1-SNAPSHOT
branch-2's are still the same.
This means if you want to commit something for beta1, commit it to
bra
+1 (non-binding)
On Thu, Aug 31, 2017 at 8:33 PM, Jian He wrote:
> Hi All,
>
> I would like to call a vote for merging yarn-native-services to trunk. The
> vote will run for 7 days as usual.
>
> At a high level, the following are the key feautres implemented.
> - YARN-5079[1]. A native YARN fram
Hi folks,
We've landed two of our beta1 features, S3Guard and TSv2, into trunk. Jian
just sent out the vote for our remaining beta1 feature, YARN native
services, but I think it's time to branch to unblock the resource profiles
merge to 3.1.
I'll cut just branch-3.0 for now, since we don't have a
If we do "fix" this in 2.8.2 we should seriously consider not doing so in
3.0.
This is a very poor practice.
I can see an argument for backward compatibility in 2.8.x line though.
On Fri, Sep 1, 2017 at 1:41 PM, Steve Loughran
wrote:
> One thing we need to consider is
>
> HADOOP-14439: regressi
One thing we need to consider is
HADOOP-14439: regression: secret stripping from S3x URIs breaks some downstream
code
Hadoop 2.8 has a best-effort attempt to strip out secrets from the toString()
value of an s3a or s3n path where someone has embedded them in the URI; this
has caused problems i
For more details, see
https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/510/
[Aug 31, 2017 9:23:17 AM] (yqlin) HDFS-12317. HDFS metrics render error in the
page of Github. Contributed
[Aug 31, 2017 1:12:01 PM] (sunilg) YARN-7116. CapacityScheduler Web UI: Queue's
AM usage is always
> On Aug 28, 2017, at 9:58 AM, Allen Wittenauer
> wrote:
> The automation only goes so far. At least while investigating Yetus
> bugs, I've seen more than enough blatant and purposeful ignored errors and
> warnings that I'm not convinced it will be effective. ("That javadoc compile
> f
HADOOP-14814 get committed and HADOOP-9747 get push out to 2.8.3, so we are
clean on blocker/critical issues now.
I finish practice of going through JACC report and no more incompatible public
API changes get found between 2.8.2 and 2.7.4. Also I check commit history and
fixed 10+ commits which
12 matches
Mail list logo
