bigtop-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leidle, Rob" <>
Subject Re: possible bug in puppet installation?
Date Sat, 29 Nov 2014 01:23:21 GMT
Thank you for the reply. I would think that is how it would work. However,
isn¹t that script starting the secondary-namenode service when ha is
³disabled²? That¹s the behavior I am seeing. I have no configured for HA
yet secondary namenode is being configured and started by the puppet

On 11/28/14, 4:07 PM, "Konstantin Boudnik" <> wrote:

>The logic here is that in HA environment you can go without a secondary
>because your standby will carry on a copy of your primary's editlogs. As
>optimization you can cut off a checkpointing overhead.
>Hope it helps,
>  Cos
>On Fri, Nov 28, 2014 at 08:06PM, Leidle, Rob wrote:
>> I am running into an issue with the puppet installation, and I think it
>>is a bug (although I don¹t want to submit a patch for it until I make
>>sure I understand the issue completely). When I do not specify a
>>secondary name node I am seeing both the namenode and the secondary name
>>node being installed and configured. The bug, I believe, is in the
>>cluster.pp file:
>> On line 224 the logic for secondary namenode is present:
>> if ($hadoop_ha == "disabled") { hadoop::secondarynamenode { "secondary
>> namenode_host => $hadoop_namenode_host,
>> namenode_port => $hadoop_namenode_port,
>> auth => $hadoop_security_authentication,
>> }
>> }
>> So, I think this is in error and the code should only execute if
>>$hadoop_ha is not equal to ³disabled². Ie change the equals to a not
>>equals. Can someone who understands these puppet scripts chime in and
>>let me know if this is the appropriate patch to make? Or am I not
>>understanding something about these installations?

View raw message