This is an automatically generated e-mail. To reply, visit:

(Updated April 21, 2016, 10:24 p.m.)

Review request for Ambari, Alejandro Fernandez, Robert Nettleton, and Sumit 

Bugs: AMBARI-16028

Repository: ambari

Description (updated)

1. During Namenode HA blueprint deployment, we configure the name nodes to 
start in active/standby mode based on the following properties
        "hadoop-env": {
          "properties" : {
            "dfs_ha_initial_namenode_active" : "host1",
            "dfs_ha_initial_namenode_standby" : "host2”
2. The current logic is to always bootstrap the name node marked as standby.
3. This will lead to the Namenode marked as Standby to never start under the 
following situation

- Cluster is deployed successfully
- Both name nodes are stopped
- Start the name node marked as standby. Namenode will never start.
- This is because the standby name node will try to bootstrap again.
- However to bootstrap a name node an active name node is required. Based on 
the HDFS logic the first step done when bootstrapping is to connect to the 
Active Namenode.
- Also there is no need to bootstrap here as the name node should already be 
bootstrapped and should come back up as “Active"

- The fix is to maintain a bootstrap marker file (similar to the way we keep a 
name node formatted marker file)
- In the INITIAL_START phase (during cluster deployment) we will always force 
bootstrap so as to enforce the name node marked as Standby to wait for the 
Active name node to come up, bootstrap and start in STANDBY node.
- Once we are out of INITIAL_START phase, we will bootstrap only if this name 
node has not been bootstrapped in the past.
- We will not enforce bootstrapping only in the INITIAL_START phase because 
there is a possibility during cluster deployment that both name nodes don’t 
start and hence bootstrapping out of INITIAL_START phase would be required in 
this case.


  ambari-server/src/test/python/stacks/2.0.6/HDFS/test_namenode.py 1c08d57 

Diff: https://reviews.apache.org/r/46544/diff/

Testing (updated)

Verified scenarios on live cluster.

mvn clean test -DskipSurefireTests
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 54.784s
[INFO] Finished at: Thu Apr 21 15:22:52 PDT 2016
[INFO] Final Memory: 64M/1172M
[INFO] ------------------------------------------------------------------------


Jayush Luniya

Reply via email to