a word of caution. according to INFRA-18748, asf infra is going to be
cutting out blind PR building. So we'll need to be sure that precommit
integration works e.g. testing PRs because there's a JIRA that a
whitelisted contributor has associated and put in patch available
status.
On Mon, Jul 22, 20
For what it's worth, in HBase we've been approximating which Hadoop
lines are EOL by looking at release rates and specifically CVE
announcements that include an affected release line but do not include
a fix for that release line. Our current approximation[1] lists 2.6,
2.7, and 3.0 as dead. So tha
+1
On Tue, Aug 20, 2019 at 10:03 PM Wangda Tan wrote:
>
> Hi all,
>
> This is a vote thread to mark any versions smaller than 2.7 (inclusive),
> and 3.0 EOL. This is based on discussions of [1]
>
> This discussion runs for 7 days and will conclude on Aug 28 Wed.
>
> Please feel free to share your
+1 (non-binding)
On Fri, Aug 23, 2019 at 9:06 PM Wangda Tan wrote:
>
> Hi devs,
>
> This is a voting thread to move Submarine source code, documentation from
> Hadoop repo to a separate Apache Git repo. Which is based on discussions of
> https://lists.apache.org/thread.html/e49d60b2e0e021206e22bb
On Mon, Aug 26, 2019 at 9:20 AM Eric Badger wrote:
>
> - Stuff has been going into branch-2 sporadically but I don't who is
> actively
> using that code other than as part of a cherrypick backwards strategy.
>
> - Should we do a 2.10.x release? Or just say "time to upgrade?"
>
> We have talked at
We should add a Pull Request Template that specifically calls out the
expectation that folks need to have a JIRA associated with their PR
for it to get reviewed. Expectations around time to response and how
to go about getting attention when things lag would also be good to
include. (e.g. are folks
speaking with my HBase hat on instead of my Hadoop hat, when the
Hadoop project publishes that there's a CVE but does not include a
maintenance release that mitigates it for a given minor release line,
we assume that means the Hadoop project is saying that release line is
EOM and should be abandone
Hi folks!
I’d like to start cleaning up our nightly tests. As a bit of low hanging fruit
I’d like to alter some of our check style rules to match what I think we’ve
been doing in the community. How would folks prefer I make sure we have
consensus on such changes?
As an example, our last nightl
Hello!
What do folks think about changing our line length guidelines to allow for 100
character width?
Currently, we tell folks to follow the sun style guide with some exception
unrelated to line length. That guide says width of 80 is the standard and our
current check style rules act as enfor
t;
>> <https://lists.apache.org/thread.html/7813c2f8a49b1d1e7655dad180f2d915a280b2f4d562cfe981e1dd4e%401406489966%40%3Ccommon-dev.hadoop.apache.org%3E>>>;
>> > -
>> >
>> https://lists.apache.org/thread.html/3e1785cbbe14dcab9bb970fa0f534811cfe00795a8cd1100580f27
Hi folks!
Which release lines do we as a community still consider actively maintained?
I found an earlier discussion[1] where we had consensus to consider branches
that don’t get maintenance releases on a regular basis end-of-life for
practical purposes. The result of that discussion was writ
Hi folks!
The consensus seems pretty strongly in favor of increasing the line length
limit. Do folks still want to see a formal VOTE thread?
> On May 19, 2021, at 4:22 PM, Sean Busbey wrote:
>
> Hello!
>
> What do folks think about changing our line length guidelines to a
+1
> On Jun 3, 2021, at 1:14 AM, 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 official announceme
Sounds good to me. That would be until Thursday June 10th, right?
As a side note it’s concerning that a double-dot maintenance release is a big
release, but I get that it’s the current state of the project.
> On Jun 3, 2021, at 11:30 AM, Wei-Chiu Chuang wrote:
>
> Hello,
> do we want to extend
Here's the email from last night to common-dev@hadoop:
https://s.apache.org/ARe1
On Wed, Oct 18, 2017 at 10:42 PM, Akira Ajisaka wrote:
> Yes, qbt runs nightly and it sends e-mail to dev lists.
> https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/
>
> Regards,
> Akira
>
>
> On 2017/
Just curious, Junping what would "solid evidence" look like? Is the
supposition here that the memory leak is within HDFS test code rather than
library runtime code? How would such a distinction be shown?
On Tue, Oct 24, 2017 at 4:06 PM, Junping Du wrote:
> Allen,
> Do we have any solid evid
The REST APIs are covered under the compatibility guidelines[1]. Presuming
these are under a new API version number, it's not clear to me from the
existing guidelines if adding one is okay in a maintenance release. It
sounds surprising to me.
[1]:
https://hadoop.apache.org/docs/current/hadoop-proj
you
> for bringing this up.
>
> regards,
> Eric
>
> On 11/16/17, 10:02 PM, "Sean Busbey" wrote:
>
> The REST APIs are covered under the compatibility guidelines[1].
> Presuming
> these are under a new API version number, it's not clear to me fr
lel of /ws/v1/* for
> 3.1 or 3.0.1 release, and deprecate /ws/v1/*. In version 4, we drop
> /ws/v1/*, right?
>
> I think this plan can work.
>
>
>
> Regards,
>
> Eric
>
>
>
>
>
> *From: *Sean Busbey
> *Date: *Friday, November 17, 2017 at 3:08 PM
>
Hi Cliff!
That looks like the result of an automated scan + exploit tool. Presuming your
cluster is not using kerberos and is accessible from the outside world it's
only a matter of time before malicious users submit jobs like this.
Please see the following guide on securing your Hadoop cluster
FYI, no images make it through ASF mailing lists. I presume the image was
of the git history? If that's correct, here's what that looks like in a
paste:
https://paste.apache.org/eRix
There are no force pushes on trunk, so backing the change out would require
the PMC asking INFRA to unblock force
I really, really like the approach of defaulting to only non-routeable
IPs allowed. it seems like a good tradeoff for complexity of
implementation, pain to reconfigure, and level of protection.
On Thu, Jul 5, 2018 at 2:25 PM, Todd Lipcon wrote:
> The approach we took in Apache Kudu is that, if Ke
the same:
>> https://issues.apache.org/jira/browse/INFRA-16727
>>
>> -S
>>
>> On Thu, Jul 5, 2018 at 11:45 AM, Sean Busbey
>> wrote:
>>
>> > FYI, no images make it through ASF mailing lists. I presume the image was
>> > of the
-1 (non-binding)
force pushes are extremely disruptive. there's no way to know who's
updated their local git repo to include these changes since the commit
went in. if a merge commit is so disruptive that we need to subject folks
to the inconvenience of a force push then we should have more toolin
Can someone please give me whatever role permissions are needed in the YARN
tracker so that I can alter fix versions? (I'm a Hadoop committer.)
-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional comma
thanks!
On 2018/08/10 14:47:12, Sunil G wrote:
> Hi Sean
> I added your name in jira committer list so that you can have the
> permissions.
>
> - Sunil
>
>
> On Fri, Aug 10, 2018 at 8:14 PM Sean Busbey wrote:
>
> > Can someone please give me whatever r
+1 (non-binding)
reviewed everything, filed an additional subtask for a very trivial
typo in the docs. should be fine to make a full issue after close and
then fix.
tried merging locally, tried running through new shell tests (both
with and without bats installed), tried making an example custom
Some talk about the MSDN-for-committers program recently passed by on a private
list. It's still active, it just changed homes within Microsoft. The
info should still be in the committer repo. If something is amiss
please let me know and I'll pipe up to the folks already plugged in to
confirming it
At the very least, I'm running through an updated shaded hadoop client
this week[1] (HBase is my test application and it wandered onto some
private things that broke in branch-2). And Sangjin has a good lead on
an lower-short-term-cost incremental improvement for runtime isolation
of apps built on
FWIW, there is a "blessed" apache area on docker hub now, and it's
just an INFRA request to point out the needed Dockerfile in the repo.
PMCs can also request write access to bintray hosting of docker images
for PMC members.
Info on INFRA-8441, example on INFRA-12019.
A Docker image that starts
thanks for bringing this up! big +1 on upgrading dependencies for 3.0.
I have an updated patch for HADOOP-11804 ready to post this week. I've
been updating HBase's master branch to try to make use of it, but
could use some other reviews.
On Thu, Jul 21, 2016 at 4:30 AM, Tsuyoshi Ozawa wrote:
> H
Folks might want to take a look at
https://issues.apache.org/jira/browse/HBASE-12721
and its associated review board posting of aggregate work. One of hte
HBase community members has been creating infra (geared towards test
ATM) for spinning up clusters of docker images. from what I
understand, r
> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still
> have the issue of things committed for 2.9.0 that will be appearing for the
> first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs,
> it's only incrementally more work to also fix up 2.8 and other unrel
On Thu, Jul 21, 2016 at 4:32 PM, Vinod Kumar Vavilapalli
wrote:
>> I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible
>> for downstreams to test incompat changes and new features without a release
>> artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready
My work on HADOOP-11804 *only* helps processes that sit outside of YARN. :)
On Fri, Jul 22, 2016 at 10:48 AM, Allen Wittenauer
wrote:
>
> Does any of this work actually help processes that sit outside of YARN?
>
>> On Jul 21, 2016, at 12:29 PM, Sean Busbey wrote:
>>
>&g
Yes, the Java API Compliance Checker allows specifying Annotations to
pare down where incompatible changes happen. It was added some time
ago based on feedback from the Apache HBase project.
The limitations I've found are: 1) at least earlier versions only
supported annotations at the class level
to 3.x will be very helpful, and it can also
>> help for people to better understand what have changed (Just like
>> http://hadoop.apache.org/docs/current/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduce_Compatibility_Hadoop1_Hadoop2.html)
>>
>> Thoughts?
>>
It's also the key Andrew has in the project's KEYS file:
http://www.apache.org/dist/hadoop/common/KEYS
On Tue, Aug 30, 2016 at 4:12 PM, Andrew Wang wrote:
> Hi Eric, thanks for trying this out,
>
> I tried this gpg command to get my key, seemed to work:
>
> # gpg --keyserver pgp.mit.edu --recv
Hi folks!
a host of precommit checks are currently timing out due to an update
to our job configs (the timeout is currently set to 50 minutes).
I'm in the process of giving things more time based on our historic
usage, but if your check fails in the mean time and
1) the total run time is close t
Should be all set now.
On Tue, Nov 8, 2016 at 5:54 PM, Sean Busbey wrote:
> Hi folks!
>
> a host of precommit checks are currently timing out due to an update
> to our job configs (the timeout is currently set to 50 minutes).
>
> I'm in the process of giving things
historically that git clean failure thing was a problem where an test
purposefully set bad permissions to simulate a disk failure that
resulted in a ro filesystem. I had thought all of the hadoop-related
precommit jobs had special handling in place to account for this test
now.
Is there a JIRA in
ues/BgcrxQqObj4.
>
> I cannot find HADOOP/YARN JIRA, please feel free to create one.
>
> Thanks,
> Wangda
>
>
> On Tue, Jan 3, 2017 at 1:04 PM, Sean Busbey wrote:
>>
>> historically that git clean failure thing was a problem where an test
>> purpose
disallowing force pushes to trunk was done back in:
* August 2014: INFRA-8195
* February 2016: INFRA-11136
On Mon, Apr 17, 2017 at 11:18 AM, Jason Lowe
wrote:
> I found at least one commit that was dropped, MAPREDUCE-6673. I was able to
> cherry-pick the original commit hash since it was recor
-dev@yetus to bcc, since I think this is a Hadoop issue and not a yetus
issue.
Please review/commit HADOOP-14686 (which I am providing as a
volunteer/contributor on the Hadoop project).
On Tue, Jul 25, 2017 at 7:54 PM, Allen Wittenauer
wrote:
>
> Again: just grab the .gitignore file fro
When Apache Yetus formed, it started with several key pieces of Hadoop that
looked reusable. In addition to our contribution testing infra, the project
also stood up a version of our audience annotations for delineating the
public facing API[1].
I recently got the Apache HBase community onto the Y
his itself an incompatible change? I imagine the bytecode will be
> different.
>
> I think we're too late to do this for beta1 given that I want to cut an
> RC0 today.
>
> On Fri, Sep 22, 2017 at 7:03 AM, Sean Busbey wrote:
>
>> When Apache Yetus formed, it started with s
Early december would be great, presuming the RC process doesn't take too
long. By then it'll already have over a month since the 2.6.2 release and
I'm sure the folks contributing the 18 patches we already have in would
like to see their work out there.
On Fri, Nov 20, 2015 at 7:51 AM, Junping Du
A layout change in a maintenance release sounds very risky. I saw some
discussion on the JIRA about those risks, but the consensus seemed to
be "we'll leave it up to the 2.6 and 2.7 release managers." I thought
we did RMs per release rather than per branch? No one claiming to be a
release manager e
2.7. In addition, I didn't see any blocker issue to bring it into
> 2.6.5 now.
> Just my 2 cents.
>
> Thanks,
>
> Junping
>
>
> From: Sean Busbey
> Sent: Thursday, March 31, 2016 2:57 PM
> To: hdfs-...@hadoop.apache.o
Next go-round can we start with a [DISCUSS] thread about suitability
for a vote first?
On Thu, Apr 28, 2016 at 4:43 PM, Wangda Tan wrote:
> Hi Vinod,
>
> Thanks for comment, since YTSv2 merge is not blocked by YARN UI merge, I
> agree to hold off YARN-3368 merge until it becomes more ready.
>
> W
A few options:
* Only change the builds for master to use jdk8
* build with both jdk7 and jdk8 by copying jobs
* build with both jdk7 and jdk8 using a jenkins matrix build
Robert, if you'd like help with any of these please send me a ping off-list.
On Tue, Apr 21, 2015 at 8:19 PM, Vinod Kumar Va
On Wed, Apr 22, 2015 at 2:10 AM, Allen Wittenauer wrote:
>
>
> * There have been a few runs which seems to indicate that *something* is
> destroying the artifact directory in the middle of runs…. which is very
> very odd and something I hadn’t seen in any of my testing. In any case, I
> clearly
On Apr 28, 2015 5:59 PM, "Sangjin Lee" wrote:
>
> That said, in a way we're deferring the cost of cleaning things up towards
> the end of the branch. For example, we don't get the same treatment of the
> hadoop jenkins in a branch development. It's left up to the group or the
> individuals to mak
you might have to do things in two steps
* move from HADOOP tracker to YARN tracker
* convert from YARN jira to subtask of YARN-3719
On Wed, May 27, 2015 at 10:52 AM, Ted Yu wrote:
> When you click on More button, you should see an action called Move.
>
> You can move the existing JIRA.
>
> FYI
Thanks for hte heads up.
On Fri, Jun 19, 2015 at 1:43 PM, Chris Nauroth
wrote:
> Hi everyone,
>
> I was just in contact with Apache infrastructure. Jenkins wasn't running
> jobs for a while, so there is a large backlog in the queue now (over 200
> jobs). Infra has fixed the problems, so jobs a
Any update on a release plan for 2.6.1?
On Wed, Jun 10, 2015 at 1:25 AM, Brahma Reddy Battula <
brahmareddy.batt...@huawei.com> wrote:
> HI vinod
>
> any update on this..? are we planning to give 2.6.1 Or can we make 2.7.1
> as stable give..?
>
>
> Thanks & Regards
> Brahma Reddy Battula
>
> ___
On Jul 8, 2015 2:13 AM, "Tsuyoshi Ozawa" wrote:
>
> +1, thanks Allen and Andrew for taking lots effort!
>
> > Is there any possibility that, we can restrict someone from editing the
> > issue in jira once its marked as "closed" after release?
>
> Vinay's comment looks considerable for us to me. Wh
If we haven't frozen yet, HDFS-8850 is a straight forward fix that is
currently only in 2.8+ and would benefit 2.6 and 2.7.
On Wed, Aug 5, 2015 at 2:56 PM, Junping Du wrote:
> I would like to nominate YARN-3832 as 2.6.1 candidate which is critical
> and I also saw it happened recently on a 2.6.0
+1
If we can make things look like HBase support for precommit testing on
branches (HBASE-12944), that would make it easier for new and occasional
contributors who might end up working in other ecosystem projects. AFAICT,
Jonathan's proposal for branch names in patch names does this.
On Wed, Ma
Hi Brahma!
Thanks for organizing this. What’s the timezone for the 10p - midnight? Pacific
Time?
> On Sep 8, 2021, at 1:17 AM, Brahma Reddy Battula wrote:
>
> Hi All,
>
> Updated the meeting to record the session.. Please use the following link
> to attend the conference tomorrow.
>
>
> Ube
I think consolidating on a common library and tooling for defining API
expectations for Hadoop would be great.
Unfortunately, the Apache Yetus community recently started a discussion around
dropping their maintenance of the audience annotations codebase[1] due to lack
of community interest. In
If you add a line in the commit message that the commit closes a given PR #
then GitHub will annotate the PR as related to the specific commit and close it
for you.
i.e. you can add “closes #3454” to the commit message body and then PR 3454
will close and link to that commit when it hits the de
Sean Busbey created YARN-8646:
-
Summary: republish 3.0.3 release notes so they include YARN-7190
Key: YARN-8646
URL: https://issues.apache.org/jira/browse/YARN-8646
Project: Hadoop YARN
Issue
Sean Busbey created YARN-5433:
-
Summary: Audit dependencies for Category-X
Key: YARN-5433
URL: https://issues.apache.org/jira/browse/YARN-5433
Project: Hadoop YARN
Issue Type: Bug
Sean Busbey created YARN-6466:
-
Summary: Provide shaded framework jar for containers
Key: YARN-6466
URL: https://issues.apache.org/jira/browse/YARN-6466
Project: Hadoop YARN
Issue Type: New
65 matches
Mail list logo
