ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Speidel" <jspei...@hortonworks.com>
Subject Re: Review Request 31231: Fixes for HA Blueprints configuration handling
Date Fri, 20 Feb 2015 20:57:38 GMT


> On Feb. 20, 2015, 7:39 p.m., Robert Levas wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java,
line 672
> > <https://reviews.apache.org/r/31231/diff/1/?file=870418#file870418line672>
> >
> >     Is `properties.get("hbase-site")` guarenteed to not return null?
> 
> Robert Nettleton wrote:
>     Thanks for the review.  I'm pretty sure that this should never return null, since
these updater implementations are only called by the processor when a given config type is
found in the proposed configuration map.  
>     
>     That being said, it makes sense to add a check here, just to be safe, so I'll add
a check for null and submit a new version of the patch.

+1. I believe this needs to be checked.


- John


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31231/#review73305
-----------------------------------------------------------


On Feb. 20, 2015, 5:58 p.m., Robert Nettleton wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31231/
> -----------------------------------------------------------
> 
> (Updated Feb. 20, 2015, 5:58 p.m.)
> 
> 
> Review request for Ambari, John Speidel and Robert Levas.
> 
> 
> Bugs: AMBARI-9733
>     https://issues.apache.org/jira/browse/AMBARI-9733
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> This patch resolves AMBARI-9733.
> 
> Some errors in the BlueprintConfigurationProcessor were
>   causing cluster deployments to fail with Blueprints
>   that were exported from HDFS HA clusters.
> 
> This patch addresses the issue by:
> 
>  - Adding some custom code to check for the case of
>    properties associated with the "SECONDARY_NAMESERVER"
>    being present in the stack during a cluster update. A
>    Blueprint exported from a running HA cluster will not
>    include this configuration, since the Secondary NameServer
>    is not present in an HA cluster.  The Blueprint config
>    processor will now detect the case of a property
>    related to the "SECONDARY_NAMESERVER", and will just
>    return the original value of the property during processing.
> 
>  - Adding some custom code to handle the formatting of
>    the "hbase.rootdir" property in the "hbase-site"
>    configuration file.  This property can have a special
>    meaning in an HA scenario, and the URL in the
>    property value will typically refer to a logical
>    nameservice, rather than a host name.  The
>    Blueprint configuration processor now detects
>    this situation in an HA environment, and will
>    leave the property unchanged, which is the correct
>    behavior for an HA cluster.
> 
>  - Adds unit test assertions to existing tests to
>    verify these fixes.
> 
> 
> Diffs
> -----
> 
>   ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
d2af1d7 
>   ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
cac1602 
> 
> Diff: https://reviews.apache.org/r/31231/diff/
> 
> 
> Testing
> -------
> 
> 1. Ran the ambari-server unit tests (all passing).
> 2. Manually verified that a 3-node HDFS HA cluster can be started with a Blueprint that
was exported from a running HDFS HA cluster (HDFS and Yarn). 
> 3. Manually verified that a 3-node HDFS HA cluster can be started with a Blueprint that
was exported from a running HDFS HA cluster with additional components that reference HDFS
(HBase, Hive, Storm, etc).
> 
> 
> Thanks,
> 
> Robert Nettleton
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message