It's a little dirty, but Mark and Jarek (presumably from BigTop) ran a patched
version with my change at MAPREDUCE-5240.
If someone can run the BigTop tests with that change (for e.g using locally
built artifacts), that can help us fix any other blockers beyond MAPREDUCE-5240
in any
Guys,
I guess what you're missing is that Bigtop isn't a testing framework for
Hadoop. It is stack framework that verifies that components are dealing with
each other nicely. Every single stack is different: Bigtop 0.5.0 differs from
0.6.0, and so on. Bigtop - as any other ASF project - has its
On May 15, 2013, at 2:54 PM, Roman Shaposhnik wrote:
This is not my argument at all. I apologize if somehow I failed to
communicate it, but here's what my argument boils down to:
given *my* experience with Hadoop 2.0.x series and Bigtop
release every time I try a different release of Hadoop
On Wed, May 15, 2013 at 10:52PM, Suresh Srinivas wrote:
Assuming that you are talking about HDFS features when you say
features going into a beta on a very short short timetable and
laundry list etc,
No, that would not be a correct assumption.
So these features are not
-0 (Binding)
I have made my opinion known in the previous thread/vote, but I have spent
enough time discussing this and need to get back to my day job. If the
community is able to get snapshots and everything else in this list merged
and stable without breaking the stack above it in two weeks it
On 15 May 2013 23:19, Konstantin Boudnik c...@apache.org wrote:
Guys,
I guess what you're missing is that Bigtop isn't a testing framework for
Hadoop. It is stack framework that verifies that components are dealing
with
each other nicely.
which to me means Some form of integration test
Cos,
On May 15, 2013, at 11:38 PM, Konstantin Boudnik wrote:
What I am seeing times and again in these endless discussion threads is this:
a) downstream or bigtop: we are seeing a bunch of integration issues with
every new feature introduced/something even a commit made
b) feature
(initially respond on general@, sorry about that. copied here)
+1 (non-binding)
From my perspective:
* The key feature that will drive me to adopt 2.x is Rolling Upgrades
* In order to get to rolling upgrades, we need a compatibility story that
is significantly better than we have today
** We
Harsh J created HADOOP-9567:
---
Summary: Provide auto-renewal for keytab based logins
Key: HADOOP-9567
URL: https://issues.apache.org/jira/browse/HADOOP-9567
Project: Hadoop Common
Issue Type:
Scott Bressler created HADOOP-9568:
--
Summary: Improve JobClient messaging by adding job name to the
output
Key: HADOOP-9568
URL: https://issues.apache.org/jira/browse/HADOOP-9568
Project: Hadoop
10 matches
Mail list logo
