Make hadoop-common use same version of avro as HBase
Key: HADOOP-7646
URL: https://issues.apache.org/jira/browse/HADOOP-7646
Project: Hadoop Common
Issue Type: Bug
Components: io
HTTP auth tests requiring Kerberos infrastructure are not disabled on
branch-0.20-security
--
Key: HADOOP-7645
URL: https://issues.apache.org/jira/browse/HADOOP-7645
On Thu, Sep 15, 2011 at 1:44 PM, Matt Foley wrote:
> On Thu, Sep 15, 2011 at 1:20 PM, Eli Collins wrote:
>
>> Hey Matt,
>>
>> Thanks for the proposal, agree we should sort these out.
>>
>> Wrt #1 IIUC the new workflow would be to use Target Version like we
>> use Fix Version today, but only set t
+1. I faced the same problems while doing the 0.20-append branch.
thanks
dhruba
On Thu, Sep 15, 2011 at 11:58 AM, Matt Foley wrote:
> Hi all,
> for better or worse, the Hadoop community works in multiple branches. We
> have to do sustaining work on 0.20, even while we hope that 0.23 will
> fin
+1 great suggestions to dev process
On Thu, Sep 15, 2011 at 1:58 PM, Matt Foley wrote:
> Hi all,
> for better or worse, the Hadoop community works in multiple branches. We
> have to do sustaining work on 0.20, even while we hope that 0.23 will
> finally replace it. Even after that happens, we
+1 for this combination.
Kihwal
On 9/15/11 3:33 PM, "Suresh Srinivas" wrote:
Matt,
+1 for Target Version field. +1 for naming convention for the jira patch
attachments.
Regards,
Suresh
On Thu, Sep 15, 2011 at 11:58 AM, Matt Foley wrote:
> Hi all,
> for better or worse, the Hadoop community
On Thu, Sep 15, 2011 at 1:20 PM, Eli Collins wrote:
> Hey Matt,
>
> Thanks for the proposal, agree we should sort these out.
>
> Wrt #1 IIUC the new workflow would be to use Target Version like we
> use Fix Version today, but only set the Fix Version when we actually
> commit to the given branch
Matt,
+1 for Target Version field. +1 for naming convention for the jira patch
attachments.
Regards,
Suresh
On Thu, Sep 15, 2011 at 11:58 AM, Matt Foley wrote:
> Hi all,
> for better or worse, the Hadoop community works in multiple branches. We
> have to do sustaining work on 0.20, even while
Hey Matt,
Thanks for the proposal, agree we should sort these out.
Wrt #1 IIUC the new workflow would be to use Target Version like we
use Fix Version today, but only set the Fix Version when we actually
commit to the given branch for the release. Seems reasonable.
Definitely better than creating
Fix the delegation token tests to use the new style renewers
Key: HADOOP-7644
URL: https://issues.apache.org/jira/browse/HADOOP-7644
Project: Hadoop Common
Issue Type: Bug
[
https://issues.apache.org/jira/browse/HADOOP-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen O'Malley resolved HADOOP-7625.
---
Resolution: Fixed
I've committed this to 205 and 20-s. It will be committed to trunk with
M
Hi all,
for better or worse, the Hadoop community works in multiple branches. We
have to do sustaining work on 0.20, even while we hope that 0.23 will
finally replace it. Even after that happens, we will then need to do
sustaining releases on 0.23 while future development goes into 0.24 or 0.25,
On 15/09/11 17:52, Jeffrey Naisbitt wrote:
Most people working on the 0.20.20x branch prefer that you still run
test-patch manually and then post the results as a comment to the Jira. If
the change is complicated enough, it's a good idea to run the tests and post
the results too.
-Jeff
Thanks,
Hi, Pavan.
I'd check out Apache Whirr, which can setup Hadoop clusters on OpenStack
Nova.
-Adrian
On Sep 14, 2011 4:53 PM, "Pavan Kulkarni" wrote:
> Hi all,
>
> I was thinking to work on a few ideas related to Hadoop.Am seeking for
> some suggestion and advice regarding the same.
> I would want
Most people working on the 0.20.20x branch prefer that you still run
test-patch manually and then post the results as a comment to the Jira. If
the change is complicated enough, it's a good idea to run the tests and post
the results too.
-Jeff
On 9/15/11 11:49 AM, "Giridharan Kesavan" wrote:
See HADOOP-7435.
On Thu, Sep 15, 2011 at 9:44 AM, Steve Loughran wrote:
> If I have some patches for the 0.20.20x branch, how do I submit them so they
> get applied and tested on that branch, rather than trunk. I have a patch
> that I want to get in there, but the JIRA process doesn't like the
>
Steve,
At the moment patch testing through jenkins is automated only for trunk.
On Thu, Sep 15, 2011 at 9:44 AM, Steve Loughran wrote:
> If I have some patches for the 0.20.20x branch, how do I submit them so they
> get applied and tested on that branch, rather than trunk. I have a patch
> tha
If I have some patches for the 0.20.20x branch, how do I submit them so
they get applied and tested on that branch, rather than trunk. I have a
patch that I want to get in there, but the JIRA process doesn't like the
(unappliable to trunk patch). I could get the patch into trunk first and
backp
[
https://issues.apache.org/jira/browse/HADOOP-7640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eli Collins resolved HADOOP-7640.
-
Resolution: Invalid
Depends on HADOOP-5640 which isn't in trunk.
> PluginDispatcher should ide
Bump up the version of aspectj
--
Key: HADOOP-7643
URL: https://issues.apache.org/jira/browse/HADOOP-7643
Project: Hadoop Common
Issue Type: Bug
Components: build, test
Affects Versions: 0.20.205.0,
create hadoop-dist module where TAR stitching would happen
--
Key: HADOOP-7642
URL: https://issues.apache.org/jira/browse/HADOOP-7642
Project: Hadoop Common
Issue Type: Improvement
Add Apache License to template config files
---
Key: HADOOP-7641
URL: https://issues.apache.org/jira/browse/HADOOP-7641
Project: Hadoop Common
Issue Type: Bug
Components: build
Affects Ve
PluginDispatcher should identify which class could not be found
---
Key: HADOOP-7640
URL: https://issues.apache.org/jira/browse/HADOOP-7640
Project: Hadoop Common
Issue Type: Improv
yarn ui not properly filtered in HttpServer
---
Key: HADOOP-7639
URL: https://issues.apache.org/jira/browse/HADOOP-7639
Project: Hadoop Common
Issue Type: Bug
Affects Versions: 0.23.0
R
On 15/09/11 10:14, Junping Du wrote:
Hello Arun and all,
I think current hadoop have a good capability of scale out but not so good at scale in. As its
design for dedicated cluster and machines, there is not too much attention for "scale in"
capability in a long time. However, I notic
On 14/09/11 22:20, Ted Dunning wrote:
This makes a bit of sense, but you have to worry about the inertia of the
data. Adding compute resources is easy. Adding data resources, not so
much.
I've done it. Like Ted says, pure compute nodes generate more network
traffic on both reads and writes,
On 15/09/11 02:01, Bharath Ravi wrote:
Thanks a lot, all!
An end goal of mine was to make Hadoop as flexible as possible.
Along the same lines, but unrelated to the above idea, was another I
encountered,
courtesy http://hadoopblog.blogspot.com/2010/11/hadoop-research-topics.html
The blog mentio
[
https://issues.apache.org/jira/browse/HADOOP-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uma Maheswara Rao G resolved HADOOP-7304.
-
Resolution: Duplicate
> BackUpNameNode is using 100% CPU and not accepting any r
Hello Arun and all,
I think current hadoop have a good capability of scale out but not so
good at scale in. As its design for dedicated cluster and machines, there is
not too much attention for "scale in" capability in a long time. However, I
noticed that there are more and more users t
29 matches
Mail list logo
