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 scripts.
On 11/28/14, 4:07 PM, "Konstantin Boudnik" <[email protected]> wrote: >The logic here is that in HA environment you can go without a secondary >node >because your standby will carry on a copy of your primary's editlogs. As >an >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: >> >> >>https://github.com/apache/bigtop/blob/master/bigtop-deploy/puppet/manifes >>ts/cluster.pp >> >> On line 224 the logic for secondary namenode is present: >> >> if ($hadoop_ha == "disabled") { hadoop::secondarynamenode { "secondary >>namenode": >> 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?
